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 -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
