|
|
 |
« Reply #15 on: May 09, 2009, 06:27:40 AM » |
|
Thanks for another good idea. Here's the interesting output:
Here's my edited /etc/pam.d/su file:
#
# The PAM configuration file for the Shadow `su' service
#
# This allows root to su without passwords (normal operation)
auth sufficient pam_rootok.so
# Uncomment this to force users to be a member of group root
# before they can use `su'. You can also add "group=foo"
# to the end of this line if you want to use a group other
# than the default "root" (but this may have side effect of
# denying "root" user, unless she's a member of "foo" or explicitly
# permitted earlier by e.g. "sufficient pam_rootok.so").
# (Replaces the `SU_WHEEL_ONLY' option from login.defs)
# auth required pam_wheel.so
# Uncomment this if you want wheel members to be able to
# su without a password.
auth sufficient pam_wheel.so trust
# Uncomment this if you want members of a specific group to not
# be allowed to use su at all.
# auth required pam_wheel.so deny group=nosu
# Uncomment and edit /etc/security/time.conf if you need to set
# time restrainst on su usage.
# (Replaces the `PORTTIME_CHECKS_ENAB' option from login.defs
# as well as /etc/porttime)
# account requisite pam_time.so
# This module parses environment configuration file(s)
# and also allows you to use an extended config
# file /etc/security/pam_env.conf.
#
# parsing /etc/environment needs "readenv=1"
session required pam_env.so readenv=1
# locale variables are also kept into /etc/default/locale in etch
# reading this file *in addition to /etc/environment* does not hurt
session required pam_env.so readenv=1 envfile=/etc/default/locale
# Defines the MAIL environment variable
# However, userdel also needs MAIL_DIR and MAIL_FILE variables
# in /etc/login.defs to make sure that removing a user
# also removes the user's mail spool file.
# See comments in /etc/login.defs
#
# "nopen" stands to avoid reporting new mail when su'ing to another user
session optional pam_mail.so nopen
# Sets up user limits, please uncomment and read /etc/security/limits.conf
# to enable this functionality.
# (Replaces the use of /etc/limits in old login)
# session required pam_limits.so
# The standard Unix authentication modules, used with
# NIS (man nsswitch) as well as normal /etc/passwd and
# /etc/shadow entries.
@include common-auth
@include common-account
@include common-session
-----------------------------------------------------------------------------
Here's the output after the edit:
root@salient:/etc/pam.d# groupadd wheel
root@salient:/etc/pam.d# tail -1 /etc/group
wheel:x:107:
root@salient:/etc/pam.d# groups sweber
users
root@salient:/etc/pam.d# usermod -g wheel sweber
root@salient:/etc/pam.d# groups sweber
wheel
root@salient:/etc/pam.d# cat /etc/passwd | grep sweber
sweber:x:1000:107:Sam Weber:/home/sweber:/bin/bash
root@salient:/etc/pam.d# exit
exit
sweber@salient:~$ su
su: Authentication failure
Notice that the authorization failure now comes immediately after entering "su". There is no password prompt in this configuration. That must mean that authorization fails before or at the following line in the su file:
auth sufficient pam_rootok.so
But if I understand PAM operation correctly, "sufficient" shouldn't act the same as a "required". Sufficient means, if you pass here, you're in, but if you don't, you get to have a whack at the stanzas that follow. Right?
When I comment out the line of interest (#auth sufficient pam_rootok.so), the suggested line (auth sufficient pam_wheel.so trust) becomes the first stanza. The results in this configuration are the same. Authorization failure upon entering "su", no password prompt. If anything is as it seems, this behavior suggests that the authorization failure is occuring prior to the invocation of the pam.d/su file. But what is upstream? It also seems clear that since a login as root works and "sudo -s" works, entering "su" results in a different authentication path. Interesting. Frustrating, but interesting.
|
