Messages in this thread | | | Subject | Re: [patch] security: fix dummy xattr functions | From | Miklos Szeredi <> | Date | Wed, 02 Jul 2008 11:28:31 +0200 |
| |
On Wed, 2 Jul 2008, James Morris wrote: > On Wed, 2 Jul 2008, Miklos Szeredi wrote: > > > So where do the dummy_ functions figure into this? As I understand, > > they are called whenever LSM is disabled, but the LSM doesn't define a > > particular hook, so there's a default implementation. Is that correct? > > If LSM is disabled, nothing is called (the security hooks are optimized > away).
Right. I meant to say "enabled", instead of "disabled" above :)
> It's for when LSM is enabled, but there is either no LSM module > selected, or as fallbacks for hooks which are not implemented by an LSM > module.
Yes, we were thinking of the fallback case. When falling back to the default, that should be equivalent to the "no LSM" case, no?
Currently it's not.
> > If so, then in theory it is still theoretically possible that with > > LSM+capabilities, the LSM doesn't explicitly stack inode_setxattr and > > inode_removexattr, and so the dummy implementation should do that > > instead. What am I missing? > > The LSM is responsible for performing this stacking (or not), depending on > which particular security models are desired. It may, for example, not > want filesystem capabilities. > > I guess it might be safer to force the LSM to override fs capabilities if > it doesn't want them, but I'd like to see what others think.
No, this patch is _not_ forcing anything is LSM defines its own inode_{set,remove}xattr methods. I agree, that should be decided by the LSM.
The patch is just fixing the fallback dummy functions to be in sync with the the disabled LSM case.
Miklos
| |