Bug 22813 - devfs messes up console ownership
Summary: devfs messes up console ownership
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: pam
Version: 1.0
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-12-24 22:15 UTC by Alex Yacoub
Modified: 2018-07-09 11:09 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2004-09-16 10:13:15 UTC
Embargoed:


Attachments (Terms of Use)
Patch to Linux-PAM that makes devfsd pam_console aware (12.12 KB, patch)
2002-07-07 15:56 UTC, W. Michael Petullo
no flags Details | Diff
RedHat clean Linux-PAM-0.75-devfsd.patch (12.36 KB, patch)
2002-07-21 14:23 UTC, 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 16:48 UTC, W. Michael Petullo
no flags Details | Diff

Description Alex Yacoub 2000-12-24 22:15:46 UTC
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-25 04:51:39 UTC
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 07:19:26 UTC
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 19:33:57 UTC
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 18:50:26 UTC
There are some more potential problems here:

1 - The usual device filenames are symlinks. You will need to add devices of the
name:
          /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
(600).

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 15:54:14 UTC
andrew 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
device.

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.

Comment 6 W. Michael Petullo 2002-07-07 15:56:27 UTC
Created attachment 64124 [details]
Patch to Linux-PAM that makes devfsd pam_console aware

Comment 7 W. Michael Petullo 2002-07-21 14:21:51 UTC
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 14:23:22 UTC
Created attachment 66188 [details]
RedHat clean Linux-PAM-0.75-devfsd.patch

Comment 9 W. Michael Petullo 2002-07-21 14:30:07 UTC
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 16:48:20 UTC
Created attachment 66189 [details]
RedHat clean Linux-PAM-0.75-devfsd.patch mit new console.perms

Comment 11 Tomas Mraz 2004-09-16 10:13:15 UTC
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.