Red Hat Bugzilla – Bug 421951
Selinux is preventing kdm to login a user
Last modified: 2008-03-30 02:02:17 EDT
Description of problem:
With selinux in enforcing mode kdm is unable to login a user.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. set selinux in enforcing mode (setenforce 1)
2. try to login in kdm
3. watch /var/log/audit.log
login would be stopped and kdm re-appears.
User is able to login
If you set selinux to permissive mode login would be possible.
Also setroubleshoot doesn't have an entry nor /var/log/messages (this was
tested on a livecd)
Created attachment 285901 [details]
audit.log after a login
I've removed the audit.log and restarted /etc/init.d/audit so that this log
file only contains the relevant messages.
How do I change to use the kdm_greeter?
1 install kdebase-workspace
2 edit /etc/sysconfig/desktop to contain:
restorecon -R -v /root
To fix labeling on /root
I am able to login but I also get the avc messages about writing to usr_t and
locale_t. This looks like a bug in kdm_greet which is opening these files for
write. It should only open them for read.
and other desktop files.
KDM, like many other things in KDE, uses KConfig to open .desktop files.
KConfig decides automatically whether to open files read-only or read-write,
using this logic:
KConfigBase::AccessMode KConfigIniBackend::accessMode() const
if (KStandardDirs::checkAccess(filePath(), W_OK))
SELinux breaks this.
This is KStandardDirs::checkAccess:
bool KStandardDirs::checkAccess(const QString& pathname, int mode)
int accessOK = access( QFile::encodeName(pathname), mode );
if ( accessOK == 0 )
return true; // OK, I can really access the file
// if we want to write the file would be created. Check, if the
// user may write to the directory to create the file.
if ( (mode & W_OK) == 0 )
return false; // Check for write access is not part of mode => bail
if (!access( QFile::encodeName(pathname), F_OK)) // if it already exists
//strip the filename (everything until '/' from the end
int pos = dirName.lastIndexOf('/');
if ( pos == -1 )
return false; // No path in argument. This is evil, we won't allow
else if ( pos == 0 ) // don't turn e.g. /root into an empty string
pos = 1;
dirName.truncate(pos); // strip everything starting from the last '/'
accessOK = access( QFile::encodeName(dirName), W_OK );
// -?- Can I write to the accessed diretory
if ( accessOK == 0 )
return true; // Yes
return false; // No
Any way to make this more SELinux-friendly?
The question is what is doing this call? Is this something execd from the login
program or run directly from the login program? It is making the assumption
that the login program can access a users homedir? If this code was being
executed in the users context and as the UID it should work. We are not
currently allowing the login programs (xdm_t) to access home directories,
because the login programs are starting to execute lots of programs without
actually logging in. Things like setting up the network, Assistive Technologies
etc. So we would like to prevent this.
(Afaik) KConfig/KStandardDirs are in kdelibs, which can potentially be called
by pretty much any other kde app or library.
But this assumption might be wrong, and why should the login program care if it
can access the homedirs. In the case of NFSV4 or afs the login program running
as a different user will not be allowed to access the homedir.
Well, that code tests if it can write to the config file and if not opens it
read only. It's true that the case where there's no read access either is not
handled in this function, but that's caught elsewhere. The problem as I
understand it (but I'm no SELinux expert) is that with SELinux, the permissions
are such that access should succeed, but SELinux blocks the access and logs an
avc warning. Rejecting the access is harmless because the config file will just
be opened read only and that's all KDM really needs, the problem is the
spurious avc. So what I'm asking is how to fix this code so it still does what
it's supposed to (checking whether the file can be opened for writing or not)
without triggering SELinux avc log entries.
Yes I can do that, but my only means to do it is to ignore all write attempts to
the homedir. So if the program was somehow subverted or someone was attempting
to subvirt it no error messages would be sent.
I will add the dontaudit in next update.
Fixed in selinux-policy-3.3.1-26.fc9
Thanks, but what I was really asking is whether we can fix the code in KDE so
you don't have to add that dontaudit. Also because this may in principle affect
other KDE apps (this code is common kdelibs code, though most other KDE apps
will not try accessing config files in users' home directories) and your
dontaudit only fixes it for KDM (but again, KDM is the only known case of this
actually happening, so maybe that's sufficient after all).