On Mon, 2008-11-17 at 10:26 -0500, Stephen Smalley wrote: > On Mon, 2008-11-17 at 09:45 -0500, Daniel J Walsh wrote: > > I have been waiting for some one else to respond to this. I think this > > would be better sent to the nsa selinux list for better discussion. > > > > The problem with your parsing of the /proc/mounts is that it would not > > give you an accurate idea of what supports and what does not support > > SELinux labeling. Also this can change over time. > > > > If I mount an ext3 file system with a context mount, then it will no > > longer allow you to set the file context. I think the best idea is just > > attempt to assign the context and if it fails, ignore the error. I > > guess you can report it, if in verbose mode as a warning. > > > > Others may have different ideas. > > You'd want to distinguish EOPNOTSUPP from other errors in that case. > But note that this won't catch certain filesystems (like the vfat > example he gave), as changing the in-core context of a file labeled via > genfscon rules is supported presently. We could possibly change that to > also return EOPNOTSUPP. > > The problem with using getfilecon() to probe for support is that SELinux > always assigns some security context to each file for access control > purposes, even if the underlying filesystem doesn't support storage. If > we had separate getfilecon() vs. getxattr() kernel interface ala > FreeBSD, applications could test for support for storage separately, but > that isn't the case and is unlikely to change. 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. 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). No chance of seeing a "supports_setfilecon" type call? Sean -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
