Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 60908 - pam_console.so doesn't handle switching device ownership when using LDAP/Kerberos for authentication
pam_console.so doesn't handle switching device ownership when using LDAP/Kerb...
Product: Red Hat Linux
Classification: Retired
Component: pam (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jindrich Novy
Aaron Brown
Depends On:
  Show dependency treegraph
Reported: 2002-03-08 16:41 EST by maynard
Modified: 2013-07-02 18:55 EDT (History)
1 user (show)

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

Attachments (Terms of Use)

  None (edit)
Description maynard 2002-03-08 16:41:11 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020212

Description of problem:
When using LDAP for username,UID/GID. Full name, and shell account info, along
with Kerberos for authentication, pam_console.so can't set ownership properly
during login. Add the user back into the local /etc/passwd and ownership is set
properly upon login once again. This looks like pam_console.so isn't checking
nss libs to determine uid settings while being called.  

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Set up LDAP user authentication database. Add your username/UID to said
database. Might as well set up a kerberos server as well and then add a
principle for your account. 
2. Set up client workstation call LDAP server for account information. Bind your
workstation to the kerberos realm. Edit /etc/pam.d/gdm to reflect new
authentication mechanisms in place. Make certain you call pam_console.so like
you should. Remove your username from local /etc/passwd and /etc/shadow.
3. Login and check /dev/dsp and /dev/mixer. See that you now don't own these
devices even though /etc/security/console.perms says you should. You'll also
notice a nice gnome-session error message about being unable to access
/dev/mixer if you start gnome.  

Actual Results:  pam_console.so didn't change ownership for console devices
listed in /etc/security/console.perms as it should. I assume because it didn't
know who to assign ownership to. 

Expected Results:  pam_console.so should check nss to determine where to read
account information from, then it should have used the standard library calls to
obtain UID/GID mappings. With this it should have changed ownership for
/dev/mixer and /dev/dsp (and whatever else happens to be set in console.perms). 

Additional info:

bash-2.05# rpm -qa | grep pam

This is Redhat 7.2. This is in preperation for a large scale deployment of
workstations running RH72, with LDAP/Kerberos authentication and AFS support.
I'm not too keen on the idea of setting various device nodes mode 666 so users
can play mp3s on each others' consoles... a fix would be most appreciated. :)
Comment 1 maynard 2002-03-19 09:42:00 EST
I think I may be wrong about this being a bug. We've changed the order of where
pam_console.so is called in the pam stack and it now sets console/device
ownership properly. Apologies for wasted effort. 

This seems to work:

[gelinas@radish gelinas]$ cat /etc/pam.d/gdm

auth       required       /lib/security/pam_securetty.so
auth       required       /lib/security/pam_nologin.so
auth       sufficient     /lib/security/pam_unix.so
auth       required       /lib/security/pam_krb5afs.so use_first_pass 
account    required       /lib/security/pam_ldap.so
account    sufficient     /lib/security/pam_unix.so
session    required       /lib/security/pam_unix.so
session    optional       /lib/security/pam_console.so
session    sufficient     /lib/security/pam_krb5afs.so


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