Red Hat Bugzilla – Bug 448039
selinux breaks winbind-based "network account" access
Last modified: 2009-12-18 01:10:05 EST
Description of problem:
I was trying to make my FC9 laptop act like a Windows machine - in that anyone
with a valid account on our Active Directory domain should be allowed to log
into it, auto-creating their own local "profile" (ie home dir)
What happened was that when I tried logging in as "domain\username" (there's a
backslash in there), pam_mkhomedir tried to create /home/DOMAIN/username and
failed - blocked by SELinux.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. configure and join AD domain
2. set "network login" for authentication and accounts
3. login as domain\username
I haven't tried it yet, but I'm sure once I disable SELinux, it will all work.
Please attach the audit.log.
Nalin and Tomas can we switch pam_mkhomdir to use oddjob?
Why switch pam_mkhomedir to use oddjob and not just tell users that they have to
use pam_oddjob_mkhomedir instead?
Authconfig now sets up pam_mkhomedir, I could change it to set up
Nalin, is it enough to replace pam_mkhomedir with pam_oddjob_mkhomedir and set
up oddjobd with chkconfig to be run on startup?
Created attachment 306635 [details]
this is the audit.log of the failed events when selinux was active.
BTW, as expected, the logins over gdm and sshd worked just fine after selinux
(In reply to comment #3)
> Why switch pam_mkhomedir to use oddjob and not just tell users that they have to
> use pam_oddjob_mkhomedir instead?
> Authconfig now sets up pam_mkhomedir, I could change it to set up
You should also look at using the "umask=0077" option. By default, RH homedirs
are "700", but when made by pam_mkhomedir, they are "755". A bit inconsistent.
I'll either change authconfig to use pam_oddjob_mkhomedir or create a helper
binary for the directory creation.
(In reply to comment #4)
> Nalin, is it enough to replace pam_mkhomedir with pam_oddjob_mkhomedir and set
> up oddjobd with chkconfig to be run on startup?
Sorry I missed that question earlier. The default ACLs set in /etc/oddjobd.conf.d/oddjobd-mkhomedir.conf don't let unprivileged users ask it to create their home directories for them, but a process running with UID 0 is allowed to request the creation a home directory on behalf of anyone. Otherwise, yes, it's as you describe.
I reported this under FC9, and I just want to say it's still a problem under FC10beta.
It's so close, if I enable winbind for User accounts and authorization, and disable selinux, then I can do the following
1. log into FC10 using Active Directory credentials, and have a new homedir automagically created the first time
2. Later, if I'm off the network, I can still login using the winbind cached creds
3. Using PEAP Wireless, when I login (using cached creds), the Wireless adapter is then able to activate and successfully connect to our corporate AD-based PEAP network.
Sound like any other OS? :-)
This is really good stuff - all that's missing is a Domain dropbox in gdm to completely satisfy hardened Windows users :-)
but selinux is still a pain in the butt...
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.
More information and reason for this action is here:
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:
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.