Tested with:
RH 8.0, PAM 0.75.
Observation:
With pam_mkhomedir.so setup in /etc/pam.d/system-auth:
"session required /lib/security/pam_mkhomedir.so"
in NIS environment the user fails to login trough ssh
due to an error from the module:
PAM-mkhomedir[3517]: unable to create directory /etc/skel
Note: "/etc/skel" is a bug in the module:
_log_err(LOG_DEBUG, "unable to create directory %s",dest);
Should be:
_log_err(LOG_DEBUG, "unable to create directory
%s",source);
The module fails to create the user homedir because the
process runs with the privileges of the user that tries
to login, therefore mkdir will fail since /home is not
user writable by default.
I also tested with:
"su - username" - FAILED.
ftp - PASSED !?
Obvious workaround for this is to change the /home
permissions to 777 (not really a bright idea) or to
chown it to a group that the users are part of and
chmod to 775 (a little bit better).
Notes:
1.Same setup works fine with PAM-0.73 on RH73.
Logged In: NO
err:
_log_err(LOG_DEBUG, "unable to create directory %s",source);
is in the source code and should be:
_log_err(LOG_DEBUG, "unable to create directory %s",dest);
I got it backwards :) sorry.
Logged In: YES
user_id=27418
This problem is caused by changes in SSH, not in libpam: SSH
no longer runs PAM session modules with root privileges,
causing the error you see above. This is generally not
fixable in PAM; either SSH should call session modules with
root privileges, in which case this is an SSH bug; or SSH
should call session modules with the user's privileges, and
what you see is what you get. And for su, no fix is ever
likely to be possible within the PAM framework. See the
mailing list archives for recent discussion of this behavior.
The bug in the error message, OTOH, has been fixed.
Logged In: NO
su also doesn't work, not just sshd. "su" calls, before the
session management code, setfsuid() so that we get at
pam_mkhomedir's mkdir with:
uid=0,gid=0,euid=0,egid=0,fsuid=505,fsgid=0
and mkdir doesn't work...
(505 is the uid of su's target user: this example was root
-> user).
Logged In: YES
user_id=978044
Shouldn't pam_mkhomedir just not assume it's being run as root?