As we develop SELinux we are adding new labels to homedir content

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/01/2012 06:14 AM, Lennart Poettering wrote:
> On Thu, 31.05.12 15:44, Daniel J Walsh (dwalsh at redhat.com) wrote:
> 
> Heya,
> 
>> We have added file trans by name rules to policy to fix a lot of 
>> files/directories being created with the correct label.
>> 
>> We have problems on Distribution updates (F16-F17) though, where there is
>> a files/directories in the homedir that are mislabeled.
>> 
>> We have "restorecond -u"  which we run in F15/F16 which examines the
>> homedir and fixes any files directories it finds mislabeled in ~.  If it
>> finds a dir which is mislabeled, it will relabel the directory and all of
>> its children. We have turned this tool off by default on the desktop in
>> F17, because filename transition rules are doing a pretty good job of
>> maintaining the labels in the homedir.  But this tool never did a great
>> job of fixing mislabeled subdirs, if the top level directory in the
>> homedir was labeled correctly. You can enable this tool with
>> /etc/xdg/autostart/restorecond.desktop
>> 
>> One possible fix to this would be to force a system relabel on everything
>> on upgrades, while this would fix the labels, it is considered to time
>> consuming. (restorecon -R -v / or touch /.autorelabel)
>> 
>> Another option would be to just relabel /home (# restorecon -R -v /home)
>> at upgrade time.  But this would also be time consuming. And would not
>> catch the cases where the homedir is not in /home.
> 
> I am strongly for this option. Allowing the user to login while the relabel
> is still in progress (like it would with restorecond, right?) sounds like a
> really bad idea... I mean, incorrect labels when used just lead to more
> incorrect labels, no? And incorrect labels also result in access errors?
> Both sound like something to avoid...
> 
> To me it appears that preupgrade should really take care of this on all 
> Fedora release updates.
> 
> If the relabelling is slow, maybe we can do something about that? Do you 
> know why it is slow? Is this more IO bound? Or is the label lookup slow and
> this is CPU bound? If the latter it might be possible to parallelize the
> relabelling?
> 
> (I wouldn't care too much about homedirs outside of /home. A not in the 
> release notes for such cases should suffice)
> 
> Lennart
> 

Well it is slow in the same sense as find /home would be slow, restorecon is
using fts or ntfs to walk the file system and reads in the SELinux Context
(getxattr), asks SELinux what it should be labeled (matchpathcon), does a
compare, if they are different, does a setxattr on the inode.  Depends on the
number of inodes in the /home dir.

You could time it doing a restorecon -R -v /home right now, my system which
has piled up a ton of crap and exploded development pools takes nearly 2 minutes.

time restorecon -R  /home

real	1m42.677s
user	0m41.747s
sys	0m39.888s


If you had Huge file systems it could take a large amount of time.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/IwAYACgkQrlYvE4MpobPrhwCgtn+VhZimc5uD6xHZoSqHwC/O
+KYAoLM0Ahv5PkumbCxT1GBU1oAL2MI7
=Qvnv
-----END PGP SIGNATURE-----