Re: Handling labeling on filesystems that don't support SELinux
On Mon, 2008-11-17 at 11:34 -0500, Stephen Smalley wrote:
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.
Managing a file essentially means "ensure the existence/absence of a
file/directory, its ownership/permissions, and contents". The first use
case that pops to mind is for NFS servers where you can't run Puppet on
the server itself (an appliance device). Then you would need to manage
the files from one or more clients.
The big difference between SELinux contexts and the other attributes is
that in the absence of uid/gid/mode being explicitly specified Puppet
sees the default as "nil". This causes Puppet to ignore those
attributes and, if creating a file, will just default to the umask/user
that Puppet is running with. With SELinux the proper way to determine
the default is to ask matchpathcon - so for any file where the user
doesn't explicitly specify a context but matchpathcon returns one there
is a non-nil default, causing Puppet to try to make the file in-sync if
the actual doesn't match it. If an NFS filesystem was mounted
at /mnt/nfs on my Fedora 9 system matchpathcon won't return a default
for /mnt/nfs/foo so Puppet won't trigger any SELinux actions (unless the
user explicitly lists a context).
> 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.
Ah, I just skimmed the script. I feel much better about this approach
now and it will hopefully suffice. Also, since the whitelist exclusion
is only for determining defaults, a user that wanted to actively manage
an SELinux context could still explicitly list it in the file attributes
and Puppet will try to set it regardless.
> 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.
We'll see how well the filesystem whitelist works. I think it will
probably be good enough - at least for the foreseeable future.
Thanks for the feedback.
Sean