Bug 22813 - devfs messes up console ownership
devfs messes up console ownership
Product: Red Hat Raw Hide
Classification: Retired
Component: pam (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Tomas Mraz
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2000-12-24 17:15 EST by Alex Yacoub
Modified: 2018-07-09 07:09 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-16 06:13:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch to Linux-PAM that makes devfsd pam_console aware (12.12 KB, patch)
2002-07-07 11:56 EDT, W. Michael Petullo
no flags Details | Diff
RedHat clean Linux-PAM-0.75-devfsd.patch (12.36 KB, patch)
2002-07-21 10:23 EDT, W. Michael Petullo
no flags Details | Diff
RedHat clean Linux-PAM-0.75-devfsd.patch mit new console.perms (13.09 KB, patch)
2002-07-21 12:48 EDT, W. Michael Petullo
no flags Details | Diff

  None (edit)
Description Alex Yacoub 2000-12-24 17:15:46 EST
I don't really know how to debug this one, but X doesn't work with devfs as
anyone other than root because of console ownership problems.

Running devfsd-2.4.0-0.43.4 with a custom kernel of the same version.
Comment 1 Alex Yacoub 2000-12-24 23:51:39 EST
Oh, nevermind, I'm an idiot.  The solution is simple and I guess the bug's
component ought to be changed to pam.  I can't seem to figure out how to do that.

Solution is to add vc/[0-9] to the <console> line in
"/etc/security/console.perms".  This needs to be done before a true 2.4-based
distribution is released.  I guess someone needs to simply go through all the
packages and make them device independent and fix devices to work in 2.4.
Changes like this that don't keep things from working under 2.2 need to be done
sooner rather than later.
Comment 2 Mike A. Harris 2001-01-03 02:19:26 EST
Changed to PAM. I'm not even sure we support devfs..  Can someone else comment
on if it is supported or not?
Comment 3 Alex Yacoub 2001-01-03 14:33:57 EST
At the moment I know that devfs isn't supported under any released RedHat distro.  I assumed that when a distro based on kernel-2.4 finally came out, it 
would have devfs support (the devfs package is in rawhide . . .)  I'm commenting about the bug because it's something that needs to be fixed in Rawhide 
if that's gonna happen.
Comment 4 Andrew Meredith 2001-02-18 13:50:26 EST
There are some more potential problems here:

1 - The usual device filenames are symlinks. You will need to add devices of the
          /dev/*/host*/bus*/target*/lun*/cd for example for cdrom devices.

2 - The existing patterns for CDs will in fact break CD access under devfs. The
pattern /dev/cdrom* will catch the directory /dev/cdroms and make it unparseable

3 - Dynamic devices inserted while the user is logged on will only come under
console.perms (and so be accessible to the user) control once the user has
logged out and back in again.
Comment 5 W. Michael Petullo 2002-07-07 11:54:14 EDT
andrew@anvil.org make some good points.  Dynamic devices, created by devfs after
a user is logged in, will not be managed correctly by pam_console.  However, our
friends at MandrakeSoft have found a solution which is quite nice.  Their PAM
rpm includes a patch called Linux-PAM-0.75-devfsd.patch.  I am not sure who
wrote it, but here is the general idea:

1: ============================================================================

The patch creates a shared object containing the function
pam_console_apply_single, which simply applies a rule from console.perms to a

2: ============================================================================

The following line is added to devfsd:

REGISTER .* CFUNCTION /lib/security/pam_console_apply_devfsd.so \
pam_console_apply_single $devpath

This line causes devfsd to use the new pam_console_apply_single function to
manage a newly created device.


That is it.  We now have a pam_console-aware devfsd.

You should find the the Linux-PAM-0.75-devfsd.patch has been uploaded with this
Comment 6 W. Michael Petullo 2002-07-07 11:56:27 EDT
Created attachment 64124 [details]
Patch to Linux-PAM that makes devfsd pam_console aware
Comment 7 W. Michael Petullo 2002-07-21 10:21:51 EDT
You should now find a second patch attached for this bug report.  It is the same
devfsd patch as before but it is tweaked to apply cleanly to the PAM sources in
the Red Hat Linux Limbo beta distribution.  Here are the steps to get this to work:

1.  Grab the PAM SRPM from limbo.
2.  rpm -Uvh pam-0.75-38.src.rpm.
3.  Copy my second patch to SOURCES, call it pam-0.75-devfsd.patch.
4.  Add the following two lines to the appropriate place in SPECS/pam.spec:
    Path56: pam-0.75-devfsd.patch
    %patch56 -p1 -b .devfsd
5.  Do a rpmbuild -ba and install
6.  Edit /etc/security/console.perms to use devfs-style device names
(/dev/v4l/video0 vs. /dev/video0).
7.  Edit /etc/devfsd.conf so that it contains the following /two/ lines:
    1: # Use pam_console to manage device permissions.
    2: REGISTER .* CFUNCTION /lib/security/pam_console_apply_devfsd.so
pam_console_apply_single $devpath

This works for me so far.  I will update my patch soon to add devfs-style device
names to /etc/security/console.perms so that step six will be uneccessary.
Comment 8 W. Michael Petullo 2002-07-21 10:23:22 EDT
Created attachment 66188 [details]
RedHat clean Linux-PAM-0.75-devfsd.patch
Comment 9 W. Michael Petullo 2002-07-21 10:30:07 EDT
I have an addition to the steps for modifying Red Hat's SRPM which are listed
above.  In step four, one should also add
%{_libdir}/security/pam_console_apply_devfsd.so to the %files section of pam.spec.
Comment 10 W. Michael Petullo 2002-07-21 12:48:20 EDT
Created attachment 66189 [details]
RedHat clean Linux-PAM-0.75-devfsd.patch mit new console.perms
Comment 11 Tomas Mraz 2004-09-16 06:13:15 EDT
This is wontfix as devfs is not supported by Red Hat/Fedora and it's
not  prefered in mainstream kernel development anyway.

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