Bug 784444

Summary: Logging in with gnome-shell with a brand new user fails
Product: [Fedora] Fedora Reporter: Simo Sorce <ssorce>
Component: oddjobAssignee: Nalin Dahyabhai <nalin>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: dominick.grift, dwalsh, mgrepl, nalin
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-01-26 20:48:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Output of restorecon obtained with script none

Description Simo Sorce 2012-01-24 23:36:17 UTC 
I created a new user (on the network in my FreeIPA server) and I use pam_oddjob_mkhomedir to let the system create the home directory at first login.

On a fully updated F16 machine this end with gnome-shell throwing an error that something went wrong, please log out and retry.

If I switch to permissive login works.

A restorecon -R on the new user home dir fixed the issue also for enforcing mode.

So apparently first homedir creation sets labels on files the wrong way.
Comment 1 Miroslav Grepl 2012-01-25 07:31:12 UTC 
Ok, could you repeat these steps for a new user and try to log in in permissive mode and look for AVC msgs

# ausearch -m avc -ts recent

we should see what is mislabeled.
Comment 2 Daniel Walsh 2012-01-25 21:22:32 UTC 
Seems like it could be an odd job problem.  Nalin doesn't oddjob do labeling on the files it creates?
Comment 3 Nalin Dahyabhai 2012-01-25 21:33:03 UTC 
What's the path to the user's home directory?
Comment 4 Simo Sorce 2012-01-25 21:45:20 UTC 
The path is /home/<name>

The fact is that there is *some* labeling, but apprently deep down in .local or similar something is not labeled correctly or does not give gnome-shell (or whetever proxy program) proper access.

Once I restorecon -R all is fine.
Comment 5 Nalin Dahyabhai 2012-01-25 21:51:13 UTC 
The full output of 'retorecon -R -v $HOME' would be useful here.
Comment 6 Simo Sorce 2012-01-26 18:11:47 UTC 
Created attachment 557718 [details]
Output of restorecon obtained with script

Ok had to use script because redirecting restorecon (or using the -o option) seem not working ...
Comment 7 Nalin Dahyabhai 2012-01-26 18:37:14 UTC 
Your home directory appears to have been labeled as type "home_root_t", which is the default label on /home, which suggests that whatever created your home directory just left the default labeling in place.

That really sounds like what would happen if you were using the regular pam_mkhomedir.so.  Can you double-check your PAM configuration to ensure that that's not what's happening here?
Comment 8 Simo Sorce 2012-01-26 19:56:55 UTC 
You are  .... correct.
I can swear I saw oddjob there ...

now the question is why authconfig --enablemkhomedir sets up pam_mkhomdir which is obviously not going to work and does not set up oddjob ?

Maybe should reassign this bug to authconfig ?
Comment 9 Nalin Dahyabhai 2012-01-26 20:18:49 UTC 
(In reply to comment #8)
> now the question is why authconfig --enablemkhomedir sets up pam_mkhomdir which
> is obviously not going to work and does not set up oddjob ?
> 
> Maybe should reassign this bug to authconfig ?

See bug #647589, I guess.
Comment 10 Simo Sorce 2012-01-26 20:48:52 UTC 

*** This bug has been marked as a duplicate of bug 647589 ***