Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 132195
Summary: | Ipod keeps saying "do not disconnect" until you "eject /dev/sda" from console | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | jeroen <jeroen> |
Component: | eject | Assignee: | Than Ngo <than> |
Status: | CLOSED DUPLICATE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | byte, davidz, markmc, moneta.mace, rh |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-08-24 10:20:32 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
jeroen
2004-09-09 19:30:12 UTC
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 *** |