Bug 139073 - pam_console_apply not called when removing device symlinks
pam_console_apply not called when removing device symlinks
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kudzu (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2004-11-12 15:12 EST by Jonathan Peatfield
Modified: 2014-03-16 22:50 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-01-20 16:44:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch for updfstab (1.01 KB, patch)
2004-11-12 15:16 EST, Jonathan Peatfield
no flags Details | Diff

  None (edit)
Description Jonathan Peatfield 2004-11-12 15:12:54 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)

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:

   <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 (at least)

How reproducible:

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- 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.
Comment 1 Jonathan Peatfield 2004-11-12 15:16:38 EST
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

lifting the pam_console_apply call code from elsewhere in updfstab.

That patch is against kudzu- from RHEL-3AS srpm.
Comment 2 Jonathan Peatfield 2004-12-21 16:36:02 EST
The same patch applies (modulo whitespace changes) to kudzu-
as released today (though it is dated 18th Oct, so it has probably
been QA'ing for a while...)
Comment 3 Tomas Mraz 2004-12-28 11:22:22 EST
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.
Comment 4 Jonathan Peatfield 2004-12-29 20:10:06 EST
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?
Comment 5 Tomas Mraz 2004-12-30 03:48:07 EST
-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.

Comment 6 Bill Nottingham 2004-12-30 03:57:18 EST
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.
Comment 7 Tomas Mraz 2004-12-30 04:05:31 EST
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.
Comment 8 Jonathan Peatfield 2005-01-05 20:45:52 EST
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. ]
Comment 10 Bill Nottingham 2005-09-21 16:23:16 EDT
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.

Comment 11 Bill Nottingham 2006-01-20 16:44:19 EST
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. 

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