Bug 432187 - eject allows inappropriate privilege escalation
eject allows inappropriate privilege escalation
Status: CLOSED DUPLICATE of bug 437362
Product: Fedora
Classification: Fedora
Component: eject (Show other bugs)
8
All Linux
low Severity high
: ---
: ---
Assigned To: Zdenek Prikryl
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-09 10:02 EST by James
Modified: 2008-03-16 05:47 EDT (History)
5 users (show)

See Also:
Fixed In Version: 2.1.5-6.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-16 05:47:49 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)

  None (edit)
Description James 2008-02-09 10:02:46 EST
Description of problem:
eject allows ordinary users to unmount volumes attached by others, INCLUDING THE
SUPERUSER, such as those mounted at boot via fstab, e.g. /boot. This really
should not be allowed to happen --- local user or not!

Version-Release number of selected component (if applicable):
eject-2.1.5-5

How reproducible:
Always.

Steps to Reproduce:
Example: /dev/sda2 is mounted on /boot. Run as an unprivileged user:

[james@harmony ~]$ 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/sda2 on /boot type ext3 (rw)
/dev/sdb1 on /media/EXT3414G001 type ext3 (rw,nosuid,nodev,uhelper=hal)
/dev/sdb2 on /media/NTFS085G001 type fuseblk
(rw,nosuid,nodev,allow_other,blksize=4096)
[james@harmony ~]$ eject /dev/sda
[james@harmony ~]$ 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/sdb1 on /media/EXT3414G001 type ext3 (rw,nosuid,nodev,uhelper=hal)
/dev/sdb2 on /media/NTFS085G001 type fuseblk
(rw,nosuid,nodev,allow_other,blksize=4096)

Actual results:
/boot is unmounted. Could cause havok if someone tries this during a kernel update.

Expected results:
User trying this is told where to go.

Additional info:
kernel-2.6.23.14-115.fc8
selinux-policy-targeted-3.0.8-81.fc8

This has been around since at least the FC6 days. See Bug 214504.
Comment 1 Zdenek Prikryl 2008-02-12 09:47:19 EST
Hello,
eject tries to unmount all mounted partitions and after that it tries to eject
device. This behavior is implicit because of CD-ROMs. If one doesn't want to
unmount partitions then he has to use parameter "-m". With this parameter, eject
doesn't try to unmount anything. So, the question is, if this implicit behavior
is wrong. I'll look inside of a code to find more information.
Comment 2 James 2008-02-12 10:06:47 EST
If I try it on an RHEL 4 update 6 machine, I get

[jhe@hep8 jhe]$ eject /dev/sda
umount: only root can unmount LABEL=/ from /
eject: unmount of `/' failed

and nothing is unmounted. This is with eject-2.0.13-11 and usermode-1.74-2.
Comment 3 Zdenek Prikryl 2008-02-12 10:45:31 EST
Yes, I in this case, the reason why is nothing unmounted is, that eject doesn't
continue with unmounting if some error occurs. And I suppose, that boot
partition is on second or latter line in /etc/fstab. So that is the reason, why
nothing is unmounted. But, if you change an order in /etc/fstab, then same error
will occur.
Comment 4 Zdenek Prikryl 2008-02-12 10:59:23 EST
Hmm, I was wrong, It seems, that the bug is somewhere else... I'll go through a
changelog in a spec file.
Comment 5 James 2008-02-12 11:08:21 EST
Some extra info. My fstab is

/dev/VolGroup00/LogVol00 /                       ext3    defaults        1 1
LABEL=/boot             /boot                   ext3    defaults        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
/dev/VolGroup00/LogVol01 swap                    swap    defaults        0 0

whereas the RHEL box's fstab looks like

LABEL=/                 /                       ext3    defaults        1 1
LABEL=/boot             /boot                   ext3    defaults        1 2
none                    /dev/pts                devpts  gid=5,mode=620  0 0
none                    /dev/shm                tmpfs   defaults        0 0
none                    /proc                   proc    defaults        0 0
none                    /sys                    sysfs   defaults        0 0
LABEL=SWAP-sda3         swap                    swap    defaults        0 0
Comment 6 Tomas Hoger 2008-03-05 03:20:42 EST
Smells like consolehelper problem...

/usr/bin/eject in Red Hat Enterprise Linux up to version 4:
-rwxr-xr-x  1 root root 23256 Nov  2  2004 /usr/bin/eject

/usr/bin/eject in current Fedora versions and Red Hat Enterprise Linux 5:
lrwxrwxrwx 1 root root 13 Sep 20 16:16 /usr/bin/eject -> consolehelper

Problem exists also on RHEL5 (for local console sessions).
Comment 7 Fedora Update System 2008-03-12 08:55:17 EDT
eject-2.1.5-6.fc7 has been submitted as an update for Fedora 7
Comment 8 Fedora Update System 2008-03-12 08:57:21 EDT
eject-2.1.5-6.fc8 has been submitted as an update for Fedora 8
Comment 9 James 2008-03-12 10:06:41 EDT
eject-2.1.5-6.fc8 from Koji:

[james@harmony ~]$ eject /dev/sda
eject: device "/dev/sda" doesn't have a removable flag

Changing to resolved, thanks guys!
Comment 10 Fedora Update System 2008-03-13 03:39:18 EDT
eject-2.1.5-6.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 11 Fedora Update System 2008-03-13 03:47:14 EDT
eject-2.1.5-6.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 12 FK 2008-03-15 12:10:49 EDT
Excuse me guys but did the above fix just brake any ability to eject any SCSI
device including ipods? I get the following:

$ eject -v /media/ipod/
eject: device name is `/media/ipod'
eject: expanded name is `/media/ipod'
eject: `/media/ipod' is not mounted
eject: `/dev/sdb2' can be mounted at `/media/ipod'
eject: checking if device "/dev/sdb2" has a removable flag
eject: device "/dev/sdb2" doesn't have a removable flag

and the ipod does not get ejected anymore.
Comment 13 Todd Zullinger 2008-03-15 15:28:47 EDT
I'm seeing the same problem ejecting an ipod.  Adding a little debug to
indicates that the FindDeviceMajorMinor function is returning the wrong device,
so the wrong path is checked for the removable flag.  Here's the output I get:

$ eject -v /dev/sdb2
eject: device name is `/dev/sdb2'
eject: expanded name is `/dev/sdb2'
eject: `/dev/sdb2' is mounted at `/media/ipod'
eject: checking if device "/dev/sdb2" has a removable flag
eject: deviceName = /dev/sdb2
eject: checking /sys/block/sda/removable for removable flag
eject: device "/dev/sdb2" doesn't have a removable flag

Checking /sys/block/sda/removable when ejecting /dev/sdb2 is clearly incorrect.
 In the case of /dev/sdb2, the device major, minor is 8,12.  CheckRemovable
ignores minor and hardcodes 0 when calling FindDeviceMajorMinor.  I'm not sure
what the best fix is, but the patch needs a little more baking. ;)
Comment 14 Zdenek Prikryl 2008-03-16 05:47:49 EDT
This wrong detection is duplicate of #437362. Will be fixed soon :-)

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

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