--- 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. > 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. Thank you. Casey Schaufler casey@xxxxxxxxxxxxxxxx -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
