Comment 3 for bug 11517

Revision history for this message
Allison Karlitskaya (desrt) wrote :

I get this with USB devices too.

If you just run 'eject' then the 'last error' message is a little bit deceptive.
 When you run eject without params it tries all of the methods of eject. In the
case of a USB device, the last eject error is "invalid argument" because it's
trying to eject a USB device as if it were a floppy (or something else).

If you say eject -s (scsi) then it only tries the one method and you get -EPERM
(permission denied).

Of course, running with sudo works.

Strangely, here's a strace from doing it as a user:

open("/dev/sdb", O_RDONLY|O_NONBLOCK) = 3
ioctl(3, SG_GET_VERSION_NUM, 0xbfce53c0) = 0
ioctl(3, SG_IO, 0xbfce4fb4) = -1 EPERM (Operation not permitted)

and one from root:

open("/dev/sdb", O_RDONLY|O_NONBLOCK) = 3
ioctl(3, SG_GET_VERSION_NUM, 0xbf92fa50) = 0
ioctl(3, SG_IO, 0xbf92f644) = 0
ioctl(3, SG_IO, 0xbf92f644) = 0
ioctl(3, SG_IO, 0xbf92f644) = 0
ioctl(3, BLKRRPART, 0x804d878) = 0
close(3) = 0

Both open the device (and succeed). Both issue the same commands. Some
internal capability check is preventing it from working if you're non-root though.

I've done some looking around in the kernel that suggests that less capability
checks are performed if the user has opened the device read-write instead of
read-only. Of course, in order for this to happen you'd need to make the raw
device node read/write to plugdev users :/