Re: [PATCH 1/2] VFS: Factor out part of vfs_setxattr so it can be called from the SELinux hook for inode_setsecctx.

[Casey Schaufler <casey@schaufler-ca.com>]

--- Stephen Smalley <sds@tycho.nsa.gov> 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@schaufler-ca.com

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.