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
[email protected]

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

Have you looked at using sudo to allow selected users to run the
required command(s) as root..


[email protected] 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
[email protected] ==============================================================

| Ted Linnell <[email protected]> |
| |
| Nunawading, Victoria , Australia | ==============================================================

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

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

[email protected] 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
[email protected] ==============================================================

| Ted Linnell <[email protected]> |
| |
| Nunawading, Victoria , Australia | ==============================================================

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