Bug 563320 - pam_mkhomedir.so doesn't implement umask on the created home folder
pam_mkhomedir.so doesn't implement umask on the created home folder
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: pam (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-02-09 15:14 EST by Corey Crawford
Modified: 2010-02-15 11:15 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-02-15 09:47:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Corey Crawford 2010-02-09 15:14:31 EST
Description of problem:
Passing "umask=0077" to pam_mkhomedir.so in /etc/pam.d/system-auth causes it to create a new home folder on login for a user who doesn't already have a home folder. All files are copied from /etc/skel/ as expected, but the home folder itself (/home/$USER) is created with permissions of 755, instead of 700 as specified by the umask.

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

How reproducible:
Always

Steps to Reproduce:
1. Enable pam_mkhomedir.so in /etc/pam.d/system-auth, with "uname=0077"
2. Login as a user who has no home directory
3. ls -l /home
  
Actual results:
User's home directory is created with permissions 755.

Expected results:
User's home directory should be created with permissions 700.

Additional info:
Comment 1 Tomas Mraz 2010-02-12 11:40:26 EST
Unfortunately I cannot reproduce the problem here. What application are you using to log in?

Note that the option is 'umask' and not 'uname' as in your 1.

Do you see something suspicious in /var/log/secure?
Comment 2 Corey Crawford 2010-02-12 14:21:37 EST
Logging in from GDM.

My mistake. I'm actually using uname=0077.
session optional pam_mkhomedir.so uname=0077

Nothing suspicious, just (for this one login):
Feb 12 12:38:27 lnxfedtest01t pam: gdm-password[1933[: pam_unix(gdm-password:session): session opened for user crawford by (uid=0)

Okay, not sure what all is pertinent, so here's everything I can think of.
This is a Fedora 12 VM on a VMWare ESXi cluster. It's using NIS from Windows Active Directory to get user names, and authenticating over Kerberos (also from Windows AD). On login, it uses AutoFS to mount an NFS share at /student/$USER. In /etc/gdm/PreSession/Default, the second line creates a symlink from /student/$USER to /home/$USER/sDrive (so /home/$USER must already be created at this point).
Comment 3 Tomas Mraz 2010-02-15 05:07:18 EST
Are you really using 'uname' instead of 'umask'? Then that is the problem - the parameter is umask, not uname!
Comment 4 Corey Crawford 2010-02-15 09:17:54 EST
Okay. I misread your first reply. My apologies.
I have now tried both "uname" and "umask" and neither has any effect.
Comment 5 Tomas Mraz 2010-02-15 09:32:29 EST
The problem is that I cannot reproduce the problem here, that is the pam_mkhomedir works fine even with non-default umask set and also code review did not reveal anything suspicious.
Comment 6 Corey Crawford 2010-02-15 09:47:31 EST
Okay. Again I have made some mistake. Removing the pam_mkhomedir.so line completely from that file has no effect. Meaning something other than pam.d/system-auth is creating the home folder, and I've been wasting your time.

My apologies. I'll keep looking.
Comment 7 Tomas Mraz 2010-02-15 10:43:32 EST
You're probably looking for password-auth.
Comment 8 Corey Crawford 2010-02-15 11:15:23 EST
You're right! Adding umask=0077 to password-auth's pam_mkhomedir.so line does cause new home folders to be created 700.

Thank you so much.

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