Red Hat Bugzilla – Bug 139073
pam_console_apply not called when removing device symlinks
Last modified: 2014-03-16 22:50:22 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 Description of problem: if a hotplug'd device is added (or rather a symlink is) which is mentioned (by the symlink name) in console.perms the pam_console_apply causes it to be chowned/chmod'd to the console user. However if the device is unplugged there is no call in the code to undo this, the symlink is simply unlink'd. By the time the user logs out any symlink isn't there so ownership (etc) is not reset. e.g. a updfstab.conf entry like: device usbdisk { # make a symlink symlink true # we expect to find a partition table partition 1 # USB pen-drive devices match hd JUMPDRIVE ... } with a console.perms entry like: <usbdisk>=/dev/usbdisk* ... <console> 0600 <usbdisk> 0660 root.disk So on attaching a matching usb pen-disk the symlink is made (/dev/usbdisk, usbdisk1 etc to sda1), and chown'd to the console user which follows the symlink and changes /dev/sda1 (etc) but on removal the symlink just goes away. Also the ownership of a mountpoint might need care (though there may be problems if something is already mounted on it), but since that will (probably) still be there when a user logs out it can still be chowned by gdm's calls to pam_console... Version-Release number of selected component (if applicable): from 0.99.99 to 1.1.22.4 (at least) How reproducible: Always Steps to Reproduce: 1. Add an entry to updfstab.conf (which uses symlink) 2. Add lines to console.perms 3. plug in device, remove, see the wrong owner/perms on /dev/sd... Actual Results: user ends up owning /dev/sd... Expected Results: they should be chown/chmod'd back to "normal". I've tried fairly hard to think of security implications but I can't see any (other than confusion for admins), so I'm leaving it as an RFE, but others may want to fix it themselves too... Additional info: I have a patch against the updfstab.c from kudzup-1.1.22.4 which seems to work for me. Based on the pam_console_apply codde elsewhere in the same file. The same patch works on kudzu back to 0.99.99 (as in RH9), and possibly earlier as well.
Created attachment 106601 [details] patch for updfstab For the case of symlinks, something like the following looks roughly right (I've been running this on ~200 machines for a few of weeks now). lifting the pam_console_apply call code from elsewhere in updfstab. That patch is against kudzu-1.1.22.4 from RHEL-3AS srpm.
The same patch applies (modulo whitespace changes) to kudzu-1.1.22.9-1 as released today (though it is dated 18th Oct, so it has probably been QA'ing for a while...)
With pam-0.77-66.1 (FC3 Updates) and pam-0.78-2 (devel) you can use pam_console_apply <device file name> - it will apply only to the filename specified on command line.
The existing code already calls /sbin/pam_console_apply -f device-name (with -r in the patch I suggested to *undo* the effects of course)... Or am I mising something really obvious?
-f parameter is for specifying alternate location of /etc/fstab file not for specifying device name. The possibility to specify device name was added in pam-0.77-66.1 and pam-0.78-2. If the symlink to the device is removed when the user is logged in the pam_console_apply must be called with -r but then it isn't possible to use the old pam_console_apply version as it would remove ownership from all devices, not just the symlinked one. So the new pam_console_apply is really necessary. If this bug should be fixed for RHEL3 U5, the new functionality of pam_console_apply must be backported to RHEL3 U5 too.
The -r is intentional.... you want to reset all devices as necessary. What happens is because of a different fstab, you'll end up having some devices that are no longer 'console' devices.
As I understand the problem, you don't want to reset all devices in this case. You want to reset only the device which is unplugged, because the user is still logged in. So if the attached patch works well it can be only because of sheer luck.
You are quite right, the code I suggested is not doing what I intended. It probably works (well enough for me) because later in the code there is another call to pam_console_apply which fixes ownerships/permissions up again. Looking at the source to pam_console_apply it isn't at all clear to me that the existing call of: /sbin/pam_console_apply -f revokeFileName -r /sbin/pam_console_apply -f outputFileName does quite the right thing either. The fstab file seems to only be used as a lookup from *directory* names to devices for the change_file() code. Since the call to reset_permissions will (as far as I can see) call chmod_files for each pattern mentioned in the console.perms file which calls change_file() for the glob expansion. This seems to reset the permissions for anything listed in the console.perms file (or am I totally misreading the code?) Surely this means that things like /dev/scanner*, /dev/fb* etc, will get reverted/chowned again. If this existing behaviour is acceptable (with the glitch in permissions/ownerships), them it might also be acceptable to move the revoke call to before the walk of the fstab (which removes symlinks), or move the removal of symlinks to after the various calls to pam_console_apply... Of course using a different version of pam might allow updfstab to avoid chown/chmod'ing them back and forth. Any better suggestions? [ Aside since this is reported only against RHEL. I see that updfstab is no longer used in FC3 so the pam_console change must have been for some other purpose. ]
Marking as ASSIGNED, however, this issue is not currently scheduled for a particular update release. If this issue is important to you, please contact Red Hat Support to get it escalated.
This problem is resolved in the next release of Red Hat Enterprise Linux, as RHEL 4 uses a different mechanism for device mounting. Red Hat does not currently plan to provide a resolution for this in a Red Hat Enterprise Linux update for currently deployed systems. With the goal of minimizing risk of change for deployed systems, and in response to customer and partner requirements, Red Hat takes a conservative approach when evaluating changes for inclusion in maintenance updates for currently deployed products. The primary objectives of update releases are to enable new hardware platform support and to resolve critical defects.