Bug 203073 - After upgrade to 3.5.4, it's not possible to safely remove usb disks
After upgrade to 3.5.4, it's not possible to safely remove usb disks
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: eject (Show other bugs)
5
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Ngo Than
: Regression
: 203504 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-18 06:33 EDT by Radek Bíba
Modified: 2007-11-30 17:11 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-23 15:49:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
KDE Software Compilation 131540 None None None Never

  None (edit)
Description Radek Bíba 2006-08-18 06:33:43 EDT
Description of problem:
I've updated my box to KDE 3.5.4, logged out and in to load the new KDE, played
with a USB disk and when I right-clicked the desktop icon and tried to safely
remove it, it didn't do anything. The icon didn't change to the one that denotes
an unmounted device, and mount sayd it was still mounted. I had to unmount it
as root.

I've tried it on another box with KDE 3.5.3, it was all OK. Then I unplugged it,
upgraded the box to 3.5.4, restarted the session, replugged and did the same
stuff with the flash disk andhit the same problem with safe removal as on the
first box.

Version-Release number of selected component (if applicable):
kdebase-3.5.4-0.2.fc5

How reproducible:
Always

Steps to Reproduce:
See above
  
Actual results:
See above

Expected results:
it should work as before

Additional info:
CDs are OK
Comment 1 Brian Daniels 2006-08-18 12:29:11 EDT
Also happening with SD card reader.  Resulted in corruption of my SD card when I
clicked on Safely Remove, waited, and then removed SD card.  

In my case the icon for the SD reader has never correctly shown
mounted/unmounted state, so I was caught off guard by the failure to unmount the
device.

Probably affects all USB storage devices.

Since this bug leads to data loss I'd recommend increasing severity to high.

Comment 2 Radek Bíba 2006-08-18 12:39:04 EDT
Oh! If KDE doesn't correctly show if the card is mounted or not then it's another
bug. Changing the severity of this one anyway - I can imagine folks not checking
the icon change and unplugging the device while still mounted.
Comment 3 Adalbert Prokop 2006-08-19 05:53:16 EDT
I can confirm this behaviour. As ordinary user one has to use command line tools
like gnome-umount to unmount the device correctly.
Comment 4 Ngo Than 2006-08-22 11:00:44 EDT
it's strange, i still cannot reproduce it on my test machine with current 
FC5-update.

there's a short list of the packages which works on my machine
kdelibs-3.5.4-0.1.fc5
kdebase-3.5.4-0.2.fc5
util-linux-2.13-0.20.4
hal-0.5.7-3.fc5.2
dbus-0.61-3.fc5.1


Could you please update all packages from FC-update and try again? Thanks
Comment 5 Ngo Than 2006-08-22 11:33:48 EDT
*** Bug 203504 has been marked as a duplicate of this bug. ***
Comment 6 Mary Ellen Foster 2006-08-22 11:36:22 EDT
There seem to be multiple media-manager related entries in the KDE 3.5.4
changelog at
http://www.kde.org/announcements/changelogs/changelog3_5_3to3_5_4.php -- scroll
down to "media manager" and take a look. I suspect one of those is what broke
it. It would be nice if there were an error message somewhere, instead of things
just silently not working ...

One possible suspect is this:
"Fix unmounting on systems that use supermount. Fixes bug 116209. See SVN commit
551890."
Comment 7 Mary Ellen Foster 2006-08-22 11:37:51 EDT
NB: here's the link to the KDE bug I referred to above
http://bugs.kde.org/show_bug.cgi?id=116209
Comment 8 Ngo Than 2006-08-22 11:43:33 EDT
i have taken a look at #116209 , the fix is correct and does not cause this 
problem.

Aas i said above it works for me with current FC5-update.

Could you please update all packages from FC-update and try again? Thanks
Comment 9 Rex Dieter 2006-08-22 11:46:31 EDT
This may be caused by a buggy /usr/bin/eject on FC5.  eject < 2.1.5 is known to
be bad (as disussed on the kde-packagers mailing list recently).
Comment 10 Mary Ellen Foster 2006-08-22 12:11:56 EDT
Out of curiosity, I just tried building an RPM (based on the FC5 spec file) out
of the latest package of eject (2.1.5) and upgrading to it. It doesn't seem to
have made a difference; I still have to "gnome-umount -p disk" (as myself; don't
need to be root) to unmount my USB memory stick.
Comment 11 Brian Daniels 2006-08-22 12:18:58 EDT
(In reply to comment #4)
> it's strange, i still cannot reproduce it on my test machine with current 
> FC5-update.
> 
> there's a short list of the packages which works on my machine
> kdelibs-3.5.4-0.1.fc5
> kdebase-3.5.4-0.2.fc5
> util-linux-2.13-0.20.4
> hal-0.5.7-3.fc5.2
> dbus-0.61-3.fc5.1
> 
> 


My current set:
kdelibs-3.5.4-0.1.fc5
kdebase-3.5.4-0.2.fc5
util-linux-2.13-0.20.4
hal-0.5.7.1-2.fc5
dbus-0.61-3.fc5.1

So, I match you in everything but hal.
yumex shows no updates available for hal on my system.

The problem is affecting me on two different systems now, an i386 one and an AMD64.
Comment 12 Radek Bíba 2006-08-23 04:32:06 EDT
If it's a problem with eject then it should be completely reassigned to its
maintaner, right? CC'ing Than.
Comment 13 Radek Bíba 2006-08-23 04:34:44 EDT
Ah, eject is owned by Than, too :) Sorry for the spam.
Comment 14 Rex Dieter 2006-08-23 11:29:21 EDT
See also upstream kde bug: http://bugs.kde.org/show_bug.cgi?id=131540
Comment 15 Ngo Than 2006-08-23 11:38:18 EDT
eject-2.1.5-0.1.fc5 will be pushed into FC5-update today. It fixes this above 
problem. Thanks for your report.
Comment 16 Brian Daniels 2006-08-23 13:21:15 EDT
Works fine on my i386 system after updating to new eject.  Thanks for the fix!
Comment 17 M. Steinborn 2006-08-23 13:56:33 EDT
yes, it corrects the bug, but it opens a security hole: _Every_ user can now
eject _any_ device, no permissions are checked.
Comment 18 Radek Bíba 2006-08-24 09:57:54 EDT
Than: thanks for the quick fix!

M. Steinborn: not sure I follow. Even the user with console lock cannot eject e.g.
a hard disk, the call fails. And if he can eject an ejectable medium, it's good,
isn't it? He's sitting on the console. And other users? I just tried to run
eject as a user who didn't own the console lock, and a messagebox was displayed
with text 'The password you typed is invalid. Please try again.' (which actually
appears to be a bug in usermode) but nothing was ejected so I don't see a
problem.
Comment 19 M. Steinborn 2006-08-24 11:37:22 EDT
I am sorry to tell you that yopu did not follow.

The point is: The new version of "eject" (eject-2.1.5-0.1.fc5) must be safe on
its own, indepently of kde/gnome/etc. You will agree to this sentence, don't you?

Let's assume sume devices (e.g. CDROMs) are mounted by fstab (if you are running
vmware-server, you may want so). Let's furethermore assume "user2" mounted the
CD-Rom device (he can do so because fstab contains the line 
/dev/hdc /media/cdrom iso9660,udf defaults,noauto,user,ro 0 0 ). Then only root
and user1 can unmount "/media/cdrom" resp. "/dev/hdc". Right?

But: Any lokal user (ownning /dev/console) can "eject /dev/hdc") and therefore
unmounting the cdrom. Is the problem now clear?


PS: At first tests I had problems with /etc/pam.d, there were some
*.rpmnew-files and therefore old files had been used. I must correct the last
post: but it opens a security hole: _Every_ *lokal* user *owning /dev/console*
can now eject _any_ device, no permissions are checked.

The same problem would occur with an usb-hdd mounted by root not intended to be
unmountable by any non-root user. Every lokal user owning /dev/console can eject
it and therefore unmount it.

Have I described the problem more understandable this time?
Comment 20 M. Steinborn 2006-08-24 11:44:06 EDT
An addition: The eject-commands have to be entered on a shell, not by any GUI.
Comment 21 Radek Bíba 2006-08-25 05:35:07 EDT
Ah, I got your point now. However, there are three possible scenarios:

1) people log into your system locally in GUI. Then, you don't have a static
entry for removable media in fstab, and once the person sitting on the console
puts e.g. a CD in, fstab is modified and the device is mounted. Only this user
and root can later eject it.

2) GUI isn't used, people log in remotely. Then, removable media aren't used on
that system at all and there's no need to worry about eject.

3) the box is accessible both remotely and locally, and a user puts a CD in,
goes away to work on the system remotely. Another user comes, logs in locally,
obtains console lock and can eject the medium although he didn't mount it. I can
imagine this scenario e.g. in a computer lab, however, working in this
environment has never been easy - removable media, although mounted by user1,
has always been accessible by user2 at least for reading, a local user was
always able to reboot the machine, kill locked X-server etc...
Comment 22 Baif 2006-10-09 23:28:34 EDT
Problem solved with FC5 updated to 2006-10-09
KDE 3.5.4-0.3.fc5

Note You need to log in before you can comment on or make changes to this bug.