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.
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.
Seems like it could be an odd job problem. Nalin doesn't oddjob do labeling on the files it creates?
What's the path to the user's home directory?
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.
The full output of 'retorecon -R -v $HOME' would be useful here.
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 ...
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?
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 ?
(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.
*** This bug has been marked as a duplicate of bug 647589 ***