Bug 203887
| Summary: | Local user can eject every device | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | M. Steinborn <gnugv_maintainer> |
| Component: | eject | Assignee: | Than Ngo <than> |
| Status: | CLOSED WORKSFORME | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5 | ||
| 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: | 2006-08-24 11:26: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: | |||
eject uses pam and does not start suid. Pam does not allow every user to eject device, but only the user, who is the owner of console, can eject every device! I have tried your above steps, it works for me! in your case, it seems user1 and user2 is the same, and "user2" is ownwer of console (ls -l /dev/console) Could you please check again? Thanks Shit... after copying some *.rpmnew-files in /etc/pam.d on the original files, I
cannot reproduce it wth the simple steps above anymore.
So let's look at the original problem on my machien which runs vmware. (Note: To
run vmware-server without cd-access-problems, automounting of cdroms has to be
disabled in order to get full access to the device file.).
In a customized multi-user-environment, the problem is still there:
Assume "/etc/fstab" contains the following line for the cdrom (Note: To run
vmware, you may wish to disable hal for "/dev/hdc", so the classic
fstab-approach will be used for cdrom's):
/dev/hdc /media/cdrom iso9660 defaults,noauto,user,ro 0 0
1. Log in by ssh as user2: mount /media/cdrom
2. Log in local by gdm as user1
3. (if not configured not to adjust owner of cdroms at gdm logins)
su -c "chown root /dev/hdc; chmod 700 /dev/hdc". Note that this step is only
there to simplify the test, "/etc/security/console.perms.d/50-default.perms"
could have been configured not to change permissions of the cdrom devices.
4. try to "eject /dev/hdc" as user1. This time it certainly will go. user1 is
owner of /dev/console, eject will start suid and will therefore (as root) be
allowed to eject the device. Bad especially in a multi user environment.
BTW: Disabling one device from being used with hal can be done as follows:
> cat /usr/share/hal/fdi/preprobe/20thirdparty/00-ignore-cd.fdi
<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
<device>
<match key="block.device" string="/dev/hdc">
<merge key="storage.automount_enabled_hint" type="bool">false</merge>
<merge key="storage.media_check_enabled" type="bool">false</merge>
</match>
</device>
</deviceinfo>
|
(tested only on i386, but probably any other platform has the same problem) Description of problem: Every user being logged in can eject any device he wants by invocing "eject /dev/<somedev>", regardless of the permissions of "/dev/<somedev>". Version-Release number of selected component (if applicable): eject-2.1.5-0.1.fc5.i386.rpm How reproducible: always Steps to Reproduce: (I am doing it with a cdrom device for simplification: You do not have to have e.g. an usb stick for testing) 1. Log in using gdm and kde (or gnome) as "user1", Note that the "/dev/hd?"-device representing the cd-rom is only accessible by "user1". For me, it's /dev/hdb: > ls -l /dev/hdb brw------- 1 msteinbo disk 3, 64 24. Aug 09:34 /dev/hdb 2. Log in remotely by ssh (or telnet) as "user2" 3. Run "eject /dev/hdb" (replate "hdb" by your cdrom device). Actual results: CD Rom is being ejected. The same you could have done with any other device like USB-Sticks, SD-Cards, hard disks (USB, Firewire) ... Expected results: Access should have been denied. Additional info: The reason for above behavia is that the program "eject" is started suid. As I am working on a production system I did not test what happens if I eject my local hard disk "/dev/hda" as great problems might occur, perhaps a DoS.