On Fri, 2008-03-07 at 11:48 -0800, Casey Schaufler wrote: > --- Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > > > > > ... > > > So this is a way for filesystem code to pass information to an LSM > > > without specifying semantics. Is there an expectation that > > > inode_getsecctx return the value sent by inode_notifysecctx, or > > > would you expect the "notify" secctx to be stored elsewhere? > > > > The former (getsecctx should return the value sent by notifysecctx). > > Not a separate value. > > Now that took me by surprise. > > I spent a good deal of time working with POSIX, so my perspective > may be a bit twisted, but I looks to me that from an interface > standpoint, inode_setsecctx and inode_notifysecctx are > indistinguishable. How would the man pages for the two differ? > Would you ever use both interfaces on the same inode? > > Don't take this as me being contrary, I really want to understand > how this makes for a better LSM, not just a bigger one. I'll try again to explain, but everything below has been said previously in this discussion. inode_setsecctx: Change the security context of an inode. Updates the incore security context managed by the security module and invokes the fs code as needed (via __vfs_setxattr_noperm) to update any backing xattrs that represent the context. Example usage: NFS server invokes this hook to change the security context in its incore inode and on the backing filesystem to a value provided by the client on a SETATTR operation. inode_notifysecctx: Notify the security module of what the security context of an inode should be. Initializes the incore security context managed by the security module for this inode. Example usage: NFS client invokes this hook to initialize the security context in its incore inode to the value provided by the server for the file when the server returned the file's attributes to the client. > > The other model I suppose would be something more along the lines of > > David Howell's interfaces for creating a task security struct with a > > particular value and then letting the caller set ->security directly. > > In this case, it would be creating an inode security struct with a > > particular value and then letting the fs code set inode->i_security > > directly. That seems non-optimal though for this situation (in David's > > case, the setup of the task security struct happens once early on, and > > then the swapping of the task security pointer happens later when > > performing actions that shouldn't be treated as happening under the > > current task's credentials). > > David has said, unless I'm remembering incorrectly again, that he > would expect NFS to use his scheme. I would be happier with a single > scheme than this pair. Which of the real/effective secctx values > would be affected by each of these interfaces? Maybe the right > thing is to have setsecctx hit the real and notifysecctx the > effective. Maybe that's a dumb idea. I hope that the interactions > between those schemes can be worked out before either gets adopted. > If not, there's likely to be tears. You're confusing the task security credentials with the inode security context again. David's work is only dealing with assuming different task credentials than the current process. Not managing the inode security contexts. -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
