On Mon, 2008-11-17 at 11:16 -0500, Sean E. Millichamp wrote:
Hmm... I believe that checking for an error at assignment time is
not
going to be a workable solution for Puppet.
The problem is that Puppet prepares what it needs to do in a transaction
before doing it. Take the situation where /usr/local is NFS mounted:
# ls -Z /usr/local/bin/foo
-rwxr-xr-x root root system_u:object_r:nfs_t:s0 /usr/local/bin/foo
# matchpathcon /usr/local/bin/foo
/usr/local/bin/foo system_u:object_r:bin_t:s0
Then you run puppet with a manifest that includes management
of /usr/local/bin/foo.
Can you explain what it means for puppet to manage a NFS-mounted
filesystem? I'd tend to think that file management would happen on the
server, not on a client. And puppet could easily run into problems with
e.g. setting ownership/mode information on a NFS-mounted filesystem due
to squashroot, uid/gid remapping, etc.
The first thing Puppet does is determine default
values. For SELinux this means a call to matchpathcon. Then Puppet
determines the current values with lgetfilecon. It notices that the
default value for the type should be bin_t, but the current is nfs_t so
it adds changing the type to its list of things to do. As it is
building this list it reports on the things it intends to do.
Once it determines all of the actions that it needs to take only then
does it perform the setfilecon call to update the context. Even if we
catch and silently ignore the error here the logging for the steps it
intends to take will occur on every single Puppet run, filling the logs
with what amounts to garbage and making email reports of changes
essentially useless (as you would get an email on every run telling you
of the changes it was going to make).
Performing a setfilecon call to the same context that exists during the
first phase to determine if a value can be set would be the only way I
could see to handle this, but it violates Puppet's promise of not
touching anything during a noop run and will update the ctime of the
file.
In the case of filesystems which behave like vfat Puppet would set the
label the first time following the mount and until it is remounted
wouldn't generate any additional messages. Filesystems which behave
like NFS are the real problem case though and NFS is far more likely to
be mounted at a spot where matchpathcon returns a default then (for
example) vfat is.
I'm not a fan of hardcoding a whitelist of supported filesystems for the
very reasons Dan mentioned but it sounds like there isn't a good option
for Puppet at the moment (and since I couldn't find any better options,
this is what is going into the next Puppet release).
Ok - that's essentially what Dan does in his /sbin/fixfiles script as
well.
No chance of
seeing a "supports_setfilecon" type call?
Possibly an interface could be added to selinuxfs and wrapped with a
libselinux function of that nature.
Or possibly we could export that via a new mount option that shows up
in /proc/mounts since we now support exporting information about context
mounts there? There are already mount options for user_xattr and acl
for example, but not explicitly for security contexts.
--
Stephen Smalley
National Security Agency