Bug 432187 - eject allows inappropriate privilege escalation
Summary: eject allows inappropriate privilege escalation
Keywords:
Status: CLOSED DUPLICATE of bug 437362
Alias: None
Product: Fedora
Classification: Fedora
Component: eject
Version: 8
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Zdenek Prikryl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-02-09 15:02 UTC by James Ettle
Modified: 2008-03-16 09:47 UTC (History)
5 users (show)

Fixed In Version: 2.1.5-6.fc8
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-03-16 09:47:49 UTC


Attachments (Terms of Use)

Description James Ettle 2008-02-09 15:02:46 UTC
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 14:47:19 UTC
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 Ettle 2008-02-12 15:06:47 UTC
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 15:45:31 UTC
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 15:59:23 UTC
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 Ettle 2008-02-12 16:08:21 UTC
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 08:20:42 UTC
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 12:55:17 UTC
eject-2.1.5-6.fc7 has been submitted as an update for Fedora 7

Comment 8 Fedora Update System 2008-03-12 12:57:21 UTC
eject-2.1.5-6.fc8 has been submitted as an update for Fedora 8

Comment 9 James Ettle 2008-03-12 14:06:41 UTC
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 07:39:18 UTC
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 07:47:14 UTC
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 16:10:49 UTC
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 19:28:47 UTC
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 09:47:49 UTC
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.