Douglas Gilbert (
Sun, 21 Nov 1999 14:39:45 -0500

Oliver Rauch wrote:
> Bob van der Poel wrote:
> > What I did was to make xsane SUID. This leaves it's own problems....
> Hi Bob,
> I don`t think this is much better.
> I suggest to create a goup "sane" or "scanner" and
> make the relevant /dev/sg? device that group and mode 660

I'm working on an additional interface to the Linux sg
driver which allows 2 ways to talk to the SCSI device:
1) write() request then read() response [existing method]
2) an ioctl() call SG_IO that has a similar effect

Now 2) is new (for Linux) and will make for simpler interface
code and allow for more flexible sg device permissions.
[ Method 1) is staying for backward compatibility, polling,
aynchronous notification and multi-threaded work.]

Now the sg device driver can do nothing about write
permissions being needed for method 1) because it involves
a write() system call. Method 2) doesn't have this restriction
but some care is needed. It is probably not a good idea to
let a user with only read permissions to a SCSI disk send
a WRITE or a FORMAT command to it. The logic for the
SG_IO ioctl() at the moment looks at the SCSI device type
(e.g. scanner, disk etc) and the SCSI coomand code. In the
case of a scanner it lets all SCSI commands through. Is this
a good idea or should some SCSI commands to a scanner be
restricted if a user does not have write permissions?

Doug Gilbert

Source code, list archive, and docs:
To unsubscribe: echo unsubscribe sane-devel | mail