High weirdness and questionable utility of restorecond

[Jonathan Abbey]

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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/selinux/attachments/20140905/228fcd57/attachment.sig>