Bug 132195

In fact, this is a "bug" present with the current situation of things.
I've had complaints from Debian users as well. Might need some gtkpod
hackage to make it all work again, properly (it's low down on my list
of things to fix)

This should have an effect on x86 users just as much as ppc users (the
iPod do not disconnect bug)

Some GNOME VFS enhancements are planned such that devices like this
will appear with the another icon and a more sane name and mount point. 

Interestingly enough, I also found (I got a Powerbook running Fedora
Rawhide and a iPod mini myself) that it isn't enough to just unmount
the storage device that is the iPod but that eject(1) is required.
However, removing the iPod after unmounting but without invoking
eject(1) should be harmless contrary to that the device itself says
"Do not disconnect"; (however the usual disclaimers apply here; don't
blame me or Red Hat if something bad happens)

So, to get this to work, I suppose eject(1) needs to be setuid root
and it should probably only work for non-privileged users on devices
mentioned in the /etc/fstab with the option 'user'. I'm not sure about
the implications of this, so I'm reassigning this bug to eject.

An interesting question is how to detect that a device requires to be
ejected. Or in other words, whether they accept the eject ioctl.

i don't see why it's a bug in eject and eject does not need to be
setsuid root for doing that. To fix this problem, you have to add the
option pamconsole in your /etc/fstab, it will work.

Please explain how you expect 'eject /dev/sda1' to work if run by a
unprivileged user that doesn't have write access to e.g. the /dev/sda1
device node?

Remember, the reason for having mount option pam_console in /etc/fstab
in the first place, is because of the fact that the /dev/blah entry
not readable/writeable by anyone but root (in the general case).

Also, making eject setuid root and, for unprivileged users, work for
*only* device files listed in the /etc/fstab with pamconsole, will
make eject on IDE Zip drives work from the Nautilus file manager.

David, i don't think it's a good idee to make eject setuid. All user
can unmount and eject the device node in this case! it causes a
security problem here.

Of course, you cannot eject the device if the you don't have the RW
access to it. But it's not the case here. with pamconsole, the
console.perms determines the permissions that will be given to
priviledged users of the console at login time.

> David, i don't think it's a good idee to make eject setuid. All user
> can unmount and eject the device node in this case! it causes a
> security problem here.

I'm certainly not suggesting to allow any random unauthorized user to
eject any device node. What I'm suggesting is to allow authorized
users at the console to eject device nodes mentioned in /etc/fstab if
the entry has a pamconsole entry. 

Just like said users are allowed to mount/umount such device nodes
even though they don't have read/write access to the device node.

> Of course, you cannot eject the device if the you don't have the RW
> access to it. But it's not the case here. with pamconsole, the
> console.perms determines the permissions that will be given to
> priviledged users of the console at login time.

This is wrong as far as FC3 works. It may have been true for FC2 with
kudzu and updfstab, but this is now replaced by hal and fstab-sync.
Just go ahead and try to plug in a USB key and see if you get access
to the device node (e.g. /dev/sda1) - the answer is that you don't.

Here's why: It would be a very severe security bug if we gave
read/write access to /dev/sda1 just because it is listed in the
/etc/fstab with the pamconsole option. This would be bad because
/dev/sda1 might be a ext3 filesystem and just because you're at the
console you shouldn't be allowed to read all of /dev/sda1 since the
ext3 filesystem could contain files not readable by your uid. 

Hence, eject needs to be setuid(1) to allow one special case: allow
priviliged users at the console to eject a device mentioned in the
/etc/fstab file if, and only if, it got the pamconsole option.

I see this on all x86 as well as PPC till today. Changing arch tag to all.

I'm having a problem on FC4t2 where even eject /dev/sda isn't making the
infamous "do not disconnect" go away.  I need to /sbin/modprobe -r ehci_hcd to
get that awful message to go away.  Is this a related problem, or should it be
filed separately?

kernel-2.6.11-1.1238_FC4

Jeff, please file a new bug (against the kernel) since what you mentioned is not
related to this bug (but important, nonetheless).

David, I've filed bug 154955.

Thanks.

(In reply to comment #2)
> However, removing the iPod after unmounting but without invoking
> eject(1) should be harmless contrary to that the device itself says
> "Do not disconnect"; (however the usual disclaimers apply here; don't
> blame me or Red Hat if something bad happens)

So, I always assumed this too (I mean, surely the kernel flushes the disk
buffers etc. when its unmounted?), but recently I ended up with HFS+ filesystem
errors when I removed the device without ejecting, but after unmounting it. At
least I think that's what caused the issue.

These are the kind of errors I was seeing:

  kernel: HFS+-fs: inconsistency in B*Tree (1,66,0,6,3)

*** This bug has been marked as a duplicate of 154955 ***