High weirdness and questionable utility of restorecond - selinux - Fedora mailing-lists

5 Sep 2014


      Hi, SELinux folk.
I've got a couple of RHEL 6 systems that have a whole lot of files on
them that I am trying to keep well labeled by using restorecond.
I have the following in my /etc/selinux/restored.conf file:
/etc/services
  /etc/resolv.conf
  /etc/samba/secrets.tdb
  /etc/mtab
  /var/run/utmp
  /var/log/wtmp
  /root/*
  /root/.ssh/*
  ~/*
The last line there is the problem.  I want to have restorecond
monitor everything created under any directory recursively anywhere
under /home on my systems, but this is not happening.
To figure out why, I'm going to be referencing the code for
restorecond located online at
http://userspace.selinuxproject.org/trac/browser/policycoreutils/restorecond...
The description of the restored.conf file at
http://selinuxproject.org/page/GlobalConfigurationFiles makes it seem
that the "~/*" line should be recursive, but I only see a simple
glob() at watch_list_add() when the first watches are added, and no
logic to add new watches for newly created subdirectories.
I'm assuming that I'm just missing it, more on this below.
When I start restorecond on our first RHEL6 box, I see the following
error:
restorecond: Unable to watch (/home/falazar/*) No such file or directory
Now, this is true, as far as it goes, because falazar is a user
account in our NIS that doesn't have a directory on this server.  He
has logged into the server in the past, though, so utmpwatcher.c is
finding his entry under /var/run/utmp.  It's not an error I care
about, but okay.
However, while I was investigating, I came across the inotify watch
limits set under /proc/sys/fs/inotify, and started looking into that.
Still thinking that restorecond should actually work recursively, I
took a look at how many directories are actually under /home on the
two RHEL6 boxes at issue.
Here's what I came up with by running
find /home -type d -ls | wc | egrep -o '^\s+([0-9]+)'
system1: 15640
system2: 1018055
And the default for /proc/sys/fs/inotify/max_user_watches is only
8192, okay.
I set max_user_watches to 2097152 so that inotify will allow up to two
million watches.
I then restart restorecond, and
** I no longer see the error about the missing user home directory. **
This is weird.  It seems to mean that the error message about the "No
such file or directory" disappears when max_user_watches is set
adequately high, which seems pretty absurd.  Looking at the version of
watch.c in
http://userspace.selinuxproject.org/trac/browser/policycoreutils/restorecond...
it appears that the code which would be distinguishing the two cases
would have to be in inotify_add_watch() itself, and that it is giving
a "no such file or directory" errno when it should be setting ENOSPC.
Given that this seems unlikely, and given that the code at
http://userspace.selinuxproject.org/trac/browser/policycoreutils/restorecond...
seems to make no provision at all for recursive inotify watches that
would implicate the default max_user_watches limit at all, I have to
think that RHEL6 is shipping something substantially different from
what's upstream at userspace.selinuxproject.org.
True?
Assuming RHEL6 has some distinctly different code in its current
policycoreutils package.. is '~/*' genuinely supported as recursive?
Is restorecond truly giving the "no such file or directory" error only
when max_watches is set too low?
Do I need to just plan on giving up on the restorecond hammer and am I
doomed to debug and fix the SELinux policy problems on these systems
that is causing files to be mislabeled in the first place?
Jon
--
-------------------------------------------------------------------------------
Jonathan Abbey                                        jonabbey@arlut.utexas.edu
Applied Research Laboratories                 The University of Texas at Austin
GPG Key: 71767586 at keyserver pgp.mit.edu, http://www.ganymeta.org/workkey.gpg