[systemd-devel] [PATCH 3/4] condition: add ConditionSELinux

[Daniel J Walsh]

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

On 04/05/2011 08:59 AM, Lennart Poettering wrote:
> On Tue, 05.04.11 08:42, Daniel J Walsh (dwalsh at redhat.com) wrote:
> 
>> systemd should check if the mount flag includes seclabel field.
>> before labeling.
>> If a file system does not support labeling or does is mounted with a
>> context mount option, the file system will not show the label seclabel.
>>
>> grep seclabel /proc/self/mountinfo
> 
> What happens if we try to relabel those file systems nonetheless? Just errors?
> 
> Hmm, we currently only relabel /run and /dev recursively, plus the
> top-level inode of all API file systems we mount. 
> 
> I presume devtmpfs and tmpfs do support "seclabel", right? Do we really
> have to code a check for this flag? Given that the list of API mount points
> we mount at early boot is pretty much fixed
> (http://cgit.freedesktop.org/systemd/tree/src/mount-setup.c#n51) we
> could just hardcod the invocation of the relabelling per-filesystem.
> 
> Do you have any particular file system in mind where we currently
> relabel where we shouldn't?
> 
> I'd like to understand what the precise implications of the seclabel
> option are, is there some doc available somewhere? The mount man page
> doesn't mention it... :-(
> 
> Lennart
> 
SECLABEL is a kernel flag that indicates that the file system supports
extended attributes file labeling.  It is not a mount option.  If you
mount with a context="system_u:object_r:TYPE_T:so" flag, then the kernel
will turn off the SECLABEL flag.  The flag will also not show up on file
systems that do not supported extended attributes.

In F14 the rc.sysinit script would execute the fixfiles restore script
if it found a /.autorelabel in the root directory.

fixfiles restore

would then look at ALL mounted file systems that did not have the
SECLABEL flag on them, and fix the labels.

I would recommend that you use fixfiles/setfiles/restorecon to relabel
the file systems you see with the autorelabel flag in them.

I still have a problem with going with the mount command writing the
/.autorelabel flag, in that an admin might want to force a relabel of
his entire file system, he currently just adds /.autorelabel.  I the new
model he would have to go to every file system and put the flag in the
root of the file system.

Or we could continue to have /.autorelabel means force a relabel
everywhere, where as .autorelabel in a file system with out
/.autorelabel will cause just that file system to be relabeled.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk2bHBkACgkQrlYvE4MpobNnlQCfXivNMJhs7aZ2kFmiaHhshIU6
ZdEAoOKNjL3vyM87yXfxHWRKdYNw5VKj
=aLG8
-----END PGP SIGNATURE-----