1. Forum
  2. Usenet
  3. COMP.UNIX.AIX

  • non-root use of scsi passthru - ioctl(DK_PASSTHRU)?

    From dramigan@gmail.com@21:1/5 to All on Fri Sep 16 05:16:22 2016
    I currently support a shared library which sends direct SCSI commands to
    the device that we attach. We present as a hard drive via Fibre Channel to
    the client OS, so we are leveraging the scdisk device driver (/dev/hdisk?).

    To differentiate between our 'pseudo' disk and other disk devices, we
    initiate a SCSI conversation, using SCSI_INQUIRY - and send via ioctl().
    On AIX that is the DK_PASSTHRU specific ioctl.

    When running as root, all is just fine.
    Unfortunately there are times when the shared library is loaded by a
    non-root process - at which point, the same ioctl() call fails with EACCES. Making the binary that loads the shared library setuid root works, but is
    not an option.

    We have tried changing owner on our /dev/hdisk entry.
    We have tried altering the permissions to 666 on our /dev/hdisk entry
    We have tried acledit to give the userid rw- permissions.

    All have resulted in the same EACCES error.

    Has anyone solved this problem - or have suggestions on how to get around
    it?

    Thanks in advance,

    jerry

    Jerry Heyman
    Principal Software Engineer
    Dell EMC
    Jerrold.Heyman@emc.com

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ted Linnell@21:1/5 to dramigan@gmail.com on Sat Sep 17 13:28:25 2016
    Have you looked at using sudo to allow selected users to run the
    required command(s) as root..


    dramigan@gmail.com wrote:


    I currently support a shared library which sends direct SCSI commands to
    the device that we attach. We present as a hard drive via Fibre Channel to >the client OS, so we are leveraging the scdisk device driver (/dev/hdisk?).

    To differentiate between our 'pseudo' disk and other disk devices, we >initiate a SCSI conversation, using SCSI_INQUIRY - and send via ioctl().
    On AIX that is the DK_PASSTHRU specific ioctl.

    When running as root, all is just fine.
    Unfortunately there are times when the shared library is loaded by a
    non-root process - at which point, the same ioctl() call fails with EACCES. >Making the binary that loads the shared library setuid root works, but is
    not an option.

    We have tried changing owner on our /dev/hdisk entry.
    We have tried altering the permissions to 666 on our /dev/hdisk entry
    We have tried acledit to give the userid rw- permissions.

    All have resulted in the same EACCES error.

    Has anyone solved this problem - or have suggestions on how to get around
    it?

    Thanks in advance,

    jerry

    Jerry Heyman
    Principal Software Engineer
    Dell EMC
    Jerrold.Heyman@emc.com ==============================================================
    | Ted Linnell <edlinnell@acslink.net.au> |
    | |
    | Nunawading, Victoria , Australia | ==============================================================

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jerry Heyman@21:1/5 to Ted Linnell on Mon Sep 19 06:28:15 2016
    On Friday, September 16, 2016 at 11:28:35 PM UTC-4, Ted Linnell wrote:
    Have you looked at using sudo to allow selected users to run the
    required command(s) as root..

    Thanks for the suggestion.
    Unfortunately, it's a database process that will load/unload this shared library on demand. Not really an opportunity to use 'sudo' here.

    jerry



    dramigan@gmail.com wrote:


    I currently support a shared library which sends direct SCSI commands to >the device that we attach. We present as a hard drive via Fibre Channel to >the client OS, so we are leveraging the scdisk device driver (/dev/hdisk?).

    To differentiate between our 'pseudo' disk and other disk devices, we >initiate a SCSI conversation, using SCSI_INQUIRY - and send via ioctl().
    On AIX that is the DK_PASSTHRU specific ioctl.

    When running as root, all is just fine.
    Unfortunately there are times when the shared library is loaded by a >non-root process - at which point, the same ioctl() call fails with EACCES. >Making the binary that loads the shared library setuid root works, but is >not an option.

    We have tried changing owner on our /dev/hdisk entry.
    We have tried altering the permissions to 666 on our /dev/hdisk entry
    We have tried acledit to give the userid rw- permissions.

    All have resulted in the same EACCES error.

    Has anyone solved this problem - or have suggestions on how to get around >it?

    Thanks in advance,

    jerry

    Jerry Heyman
    Principal Software Engineer
    Dell EMC
    Jerrold.Heyman@emc.com ==============================================================
    | Ted Linnell <edlinnell@acslink.net.au> |
    | |
    | Nunawading, Victoria , Australia | ==============================================================

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)