On Mon, Jun 04, 2007 at 10:36:26PM -0700, Scott Rotondo wrote: > > > In order to ease the porting of ZFS to BSD and MacOS X the following > > "system" attributes will be supported in ZFS. Setting these > > attributes requires PRIV_FILE_FLAG_SET. Clearing the attribute > > requires a process to have PRIV_FILE_FLAG_CLEAR > > You're requiring two different privileges, depending on whether the > attribute is set or cleared? That's contrary to the way other Solaris > privileges work, where a single privilege lets you set a given attribute > (say, file permission bits) regardless of the value being set.
I seem to recall a conversation on #onnv about how one could implement the BSD notion of security run levels: make sure that no process remains or can be started with PRIV_FILE_FLAG_CLEAR and IMMUTABLE or APPEND ONLY files truly are, until next boot. Mark enough files IMMUTABLE or APPEND ONLY and drop PRIV_FILE_FLAG_CLEAR early enough at boot and you're set. Now, one thing is that PRIV_FILE_FLAG_CLEAR should be possible to drop and yet one should still be able to perform some operations that currently require all privs (e.g., non-destructive DTrace scripts that use the fbt provider, or mdb -k, but not mdb -kw), just not operations that require all privileges and let the user work around these file attributes. Of course, that may be more difficult to work out than it may at first seem: one would have to be able to mark certain SMF services as IMMUTABLE, but one could not mark the repository that way without causing all SMF services to become IMMUTABLE. But at least having the split privileges now should make it easier to work this out later. Nico --
