Bug 476784 - broken "create home directories on first login" option
broken "create home directories on first login" option
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: authconfig (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
: Reopened, Triaged
: 476674 568839 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-16 23:24 EST by Roland McGrath
Modified: 2010-10-05 10:28 EDT (History)
10 users (show)

See Also:
Fixed In Version: authconfig-6.1.2-1.fc13
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-10-05 10:28:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Roland McGrath 2008-12-16 23:24:27 EST
Description of problem:


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

selinux-policy-targeted-3.5.13-34.fc10.noarch
gdm-2.24.1-2.fc10.i386
authconfig-gtk-5.4.4-1.fc10.i386

How reproducible:
100%

Steps to Reproduce:
1.in system-config-authentication, go to Options tab, check "Create home directories on first login" checkbox, hit OK
2.add a user whose home dir does not exist (in my case, the user is from NIS, with home dir in /home/username)
3.use gdm login screen to log in as that user
  
Actual results:
An error dialog about "/home/something/.ICEsomething".
Dismiss that and it just sits forever with a busy cursor
and a default background, never logs in or errors out.

Expected results:
Log me in, create the home dir.

Additional info:

setroubleshoot complains and says I have to fix it by running setsebool -P polyinstantiate_something.  Doing what it says does not make it work.
'echo 0 > /selinux/enforce' makes it work just fine (but it leaves the new homedir improperly labelled, I think).

No setsebool magic should be required.  If something like that is needed, system-config-authentication should do it.
Comment 1 Daniel Walsh 2008-12-17 09:44:28 EST
I believe the problem here is the adding of pam_mkhomedir instead of using pam_oddjob_mkhomedir.  pam_mkhomedir forces us to add a lot of heavy privs to login programs, like the ability to totally control user content.

I would like to prevent this since allowing it would allow compromized apps like gdm and sshd to manipulate the homedir without the attacker having to login.
Comment 2 Tomas Mraz 2008-12-19 04:18:03 EST
*** Bug 476674 has been marked as a duplicate of this bug. ***
Comment 3 Tomas Mraz 2008-12-22 03:36:00 EST
I'm currently changing pam_mkhomedir module to call a helper. I do not like using the oddjob_mkhomedir.
Comment 4 Tomas Mraz 2009-01-19 10:42:32 EST
The pam-1.0.90-2.fc11 in tomorrows rawhide contains the modified pam_mkhomedir which calls the helper.

Now the selinux policy has to be modified accordingly - that is add a new domain for the /sbin/mkhomedir_helper and add auto transition from the confined login contexts to this domain and allow this domain creation of the home directories and copying contents of skel to them.
Comment 5 Daniel Walsh 2009-01-19 15:46:25 EST
If you label it oddjob_mkhomedir_exec_t does it work?
Comment 6 Tomas Mraz 2009-01-20 08:03:31 EST
Yes, it works. Actually it partially works even if I do not relabel the mkhomedir_helper but I put the module after 'pam_selinux.so open'. But in that case the home directory and it's contents which was copied from skel get home_root_t labels. And this wrong labelling happens regardless of the label on the /sbin/mkhomedir_helper.

This should be solved in the policy somehow, because the system-auth where authconfig places the pam_mkhomedir is included now after the pam_selinux open call.
Comment 7 Daniel Walsh 2009-01-20 10:50:54 EST
Well that is a problem.  The only reason this works at all is that you are logging in as unconfined_t and this is allowed to create the homedir,  If you used a confined user this would fail.  The policy to create the home dir is contained in oddjob_mkhomedir_exec_t, and this executable has the knowledge to label the directory correctly.  Your helper needs to be calling matchpathcon for each file in /etc/skel to make sure it creates everything correctly.  I would suggest we combine your helper app ahd oddjob_mkhomedir together.  Any executable that is executed after the pam_selinux_open is going to be run in the users context.

The correct way to do this might be to move to a dbus system service where the login programs send a dbus message which causes the labeling to happen.
Comment 8 Tomas Mraz 2009-01-20 12:08:54 EST
I'd still like to avoid dbus dependency on the base pam package.

As the change to move the system-auth after pam_selinux open is just in rawhide I might probably back it out. If this is necessary for some other module we could even split the session part of system auth to another file which would contain the modules which need to run with the final user context.
Comment 9 Daniel Walsh 2009-01-21 09:12:19 EST
Well pam_mkhomedir should probably not be in the base package...  We have better ways to do this, then trying to hack around with pam base.
Comment 10 Bug Zapper 2009-11-18 05:29:50 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 11 Bug Zapper 2009-12-18 02:19:11 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 12 Chris Carpenter 2010-02-24 10:59:22 EST
(In reply to comment #11)
> Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
> no longer maintained, which means that it will not receive any further 
> security or bug fix updates. As a result we are closing this bug.
> 
> If you can reproduce this bug against a currently maintained version of 
> Fedora please feel free to reopen this bug against that version.
> 
> Thank you for reporting this bug and we are sorry it could not be fixed.    

This is still an issue for me in fedora 12. Could someone please look into it? I know next to nothing about selinux.
Comment 13 Daniel Walsh 2010-02-24 12:01:19 EST
Yes can you use pam_oddjob_mkhomedir instead 

This will work with SELinux.
Comment 14 Chris Carpenter 2010-02-24 13:17:58 EST
(In reply to comment #13)
> Yes can you use pam_oddjob_mkhomedir instead 
> 
> This will work with SELinux.    

I have no idea what that is or how to use it instead.
Comment 15 Daniel Walsh 2010-02-24 13:38:17 EST
http://people.redhat.com/nalin/oddjob/README.html

# yum install oddjob\*
# man pam_oddjob_mkhomedir


This will tell  you how to set it up.
Comment 16 Chris Carpenter 2010-02-24 14:50:24 EST
Well, I looked into that(both man page and website) and it looked, at least to me, like all the configuration was set up properly. I added session optional /lib/security/pam_oddjob_mkhomedir.so(from the man page) to /etc/pam.d/system-auth-ac and commented out session optional pam_mkhomedir.so. I then did chkconfig oddjobd on and service start oddjobd. 
The problem from the bug is still happening. I'm sure i'm missing something, but could you help me with what it is?
Comment 17 Daniel Walsh 2010-02-24 16:42:39 EST
Are you getting avc messages?  You removed pam_mkhomedir?
Comment 18 Chris Carpenter 2010-02-24 17:05:19 EST
(In reply to comment #17)
> Are you getting avc messages?  You removed pam_mkhomedir?    

Well, I don't see a way to remove pam_mkhomedir, at least not with yum. As far as the avc messages, i have many repeating messages of the following:

type=AVC msg=audit(1267048768.008:166): avc:  denied  { write } for  pid=6254 comm="xauth" name="cc0164937" dev=dm-0 ino=657401 context=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:home_root_t:s0 tclass=dir

Using ls -Z i see that after the directory is made it lists: unconfined_u:object_r:home_root_t:s0

The other home directories are:
unconfined_u:object_r:user_home_dir_t:s0

After i do restorecon -R /home/<username> it is:
unconfined_u:object_r:user_home_dir_t:s0

Just like the others.
Comment 19 Chris Carpenter 2010-02-24 17:06:24 EST
I apologize for the double comment, but I forgot to add that after the restorecon command i can successfully log in.
Comment 20 Daniel Walsh 2010-02-24 17:25:29 EST
Chris remove pam_mkhomedir from the /etc/pam.d/* files.
Comment 21 Chris Carpenter 2010-02-24 17:48:32 EST
Okay, that's what I was missing. I removed it from system-auth but didn't even look in the other files. After removing pam_mkhomdir from all files in /etc/pam.d/* , as well as adding oddjob to them all, it works! Any chance this could become automatic/more well documented? 

Thanks!
Comment 22 Roland McGrath 2010-02-24 17:59:51 EST
The "solution" of "use this nonstandard plug-in and fiddle config files by hand" is not an acceptable solution.  There is a check-box in the admin interface presented by the vanilla install, SELinux is enabled in the vanilla install, and they don't work together.  That's just broken out of the box.

Fortunately comment#3 indicates an intent to actually fix the bug.  When that's done, this report can be closed.  It's certainly fine with me if that fix doesn't hit until F-13 (or even F-14).  Just indicate "fixed in version" and such accurately when you close this bug.
Comment 24 Daniel Walsh 2010-02-26 15:49:54 EST
*** Bug 568839 has been marked as a duplicate of this bug. ***
Comment 25 Tomas Mraz 2010-03-30 08:41:57 EDT
The new authconfig in which is waiting for push to F13 testing uses pam_oddjob_mkhomedir if the appropriate package is installed. Someone still needs to add the oddjob-mkhomedir to comps to be installed by default though.

In case the pam_oddjob_mkhomedir is not available authconfig will use pam_mkhomedir.
Comment 26 Nalin Dahyabhai 2010-04-01 17:13:58 EDT
If it needs to be installed by default, then authconfig should just require it.  It'll probably also need to manage an ACL file for the service: the 'mkmyhomedir' method is not allowed to unprivileged users by default, but since configuration files are merged, dropping one in that allows them to use it can save you the trouble of having to edit the file that comes with the package.

<oddjobconfig>
 <service name="com.redhat.oddjob_mkhomedir">
  <object name="/">
   <interface name="com.redhat.oddjob_mkhomedir">
    <method name="mkmyhomedir">
     <allow min_uid="500"/>
    </method>
   </interface>
  </object>
 </service>
</oddjobconfig>
Comment 27 Tomas Mraz 2010-04-06 03:59:04 EDT
No, authconfig will not require it. I want to keep the requires on authconfig on the bare minimum. As the pam_oddjob_mkhomedir is run as root uid, the ACL should not be needed or am I wrong?
Comment 28 Nalin Dahyabhai 2010-04-06 13:29:50 EDT
(In reply to comment #27)
> No, authconfig will not require it. I want to keep the requires on authconfig
> on the bare minimum. As the pam_oddjob_mkhomedir is run as root uid, the ACL
> should not be needed or am I wrong?    

When run as root, it requests a method ("mkhomedirfor") which root is authorized to use, yes.  But I thought the original motivation was to handle the cases where the calling application had already dropped privileges to those of a non-root user, and for those cases an ACL entry needs to be added for that method ("mkmyhomedir").
Comment 29 Tomas Mraz 2010-04-06 16:40:09 EDT
Not for PAM. The only motivation here was to overcome the SELinux policy restrictions so the process that's creating the home directory does not run with the user context.
Comment 30 Daniel Walsh 2010-04-07 10:13:31 EDT
Can't authlogin request packages based on path if they are not installed.  Seems silly to be installing all possible login methods by default.  If a admin wants to setup user accounts to be autocreated, we should you yum to add the package if it is not installed.

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