Redhat bug says: Description of problem: Running eject /dev/hda (my hard disc) as an unprivileged user causes /boot (and other filesystems) to be unmounted. The program returns an invalid argument error, but the following is left in dmesg: ide_do_rw_disk - bad command: dev hda: flags = REQ_RW REQ_SOFTBARRIER REQ_NOMERGE REQ_STARTED REQ_ELVPRIV REQ_BLOCK_PC sector 41895, nr/cnr 8/1 bio 00000000, biotail 00000000, buffer 00000000, data 00000000, len 0 cdb: 1b 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 Version-Release number of selected component (if applicable): kernel-2.6.18-1.2798.fc6 eject-2.1.5-4.1.fc6 How reproducible: Always. Steps to Reproduce: 1. eject /dev/hda Actual results: $ mount /dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) tmpfs on /dev/shm type tmpfs (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) /dev/hda2 on /boot type ext3 (rw) /dev/hda1 on /mnt/winxp type ntfs (ro,noexec,umask=0222) $ eject /dev/hda eject: unable to eject, last error: Invalid argument $ mount /dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) tmpfs on /dev/shm type tmpfs (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) Expected results: /boot and others stay mounted!
I cannot reproduce it here, but the output seems a bit odd: $ eject /dev/hda Error: could not determine real path of the device: No such file or directory eject: unmount of `/' failed
base-system please advise.
(In reply to comment #2) > base-system please advise. I cannot reproduce it on my stable servers (/ raid), or my unstable arches (/ ext3 single disk). The eject code is pretty simple also, it just seeds the eject io. However, it does unmount all partitions on the same disk, so if you eject /dev/sda6 (or a directory mounted on /dev/sda6) it will umount /dev/sda[0-9]*. eject does not try to raise it's privilege level in any way, so if this is an error it's in the kernel or the user stupidly has the binary suid in which case I'd say this is expected behaviour.
Thx Uberlord. Closing this one as INVALID.
if anything, that bug report makes it look like a bug in the kernel, not in the userspace eject utility
