Messages in this thread | | | Date | Mon, 11 Jul 2005 12:51:35 -0500 | From | serue@us ... | Subject | Re: [patch 5/12] lsm stacking v0.2: actual stacker module |
| |
Thanks Stephen.
More comments below. This finally proves that I need to provide some documentation for each hook under stacker showing how modules are expected to interact. This hopefully will help me catch things like this. Hopefully it would also be useful to module writers in general.
Quoting Stephen Smalley (sds@epoch.ncsc.mil): > On Thu, 2005-06-30 at 14:50 -0500, serue@us.ibm.com wrote: > > Adds the actual stacker LSM. > <snip> > > +static int stacker_inode_getsecurity(struct inode *inode, const char *name, void *buffer, size_t size) > > +{ > > + RETURN_ERROR_IF_ANY_ERROR(inode_getsecurity,inode_getsecurity(inode,name,buffer,size)); > > +} > > + > > +static int stacker_inode_setsecurity(struct inode *inode, const char *name, const void *value, size_t size, int flags) > > +{ > > + RETURN_ERROR_IF_ANY_ERROR(inode_setsecurity,inode_setsecurity(inode,name,value,size,flags)); > > +} > > + > > +static int stacker_inode_listsecurity(struct inode *inode, char *buffer, size_t buffer_size) > > +{ > > + RETURN_ERROR_IF_ANY_ERROR(inode_listsecurity,inode_listsecurity(inode,buffer, buffer_size)); > > +} > > These hooks pose a similar problem for stacking as with the > [gs]etprocattr hooks, although [gs]etsecurity have the benefit of > already taking a distinguishing name suffix (the part after the > security. prefix). Note also that inode_getsecurity returns the number > of bytes used/required on success. > > The proposed inode_init_security hook will likewise have an issue for > stacking.
I can imagine a few ways of fixing this:
1. We simply expect that only one module use xattrs. This is probably unacceptable, as we will want both EVM and selinux to store xattrs.
2. A module registers an xattr name when it registers itself. Then only the registered module is consulted on one of these calls. If no module is registered, all are consulted as they are now.
This prevents a module like capability from deciding based on its own credentials whether another module's hook should be called. Is that a good or bad thing?
This might have the added bonus of obviating the need for a separate cap_stack module.
3. We return an error <0 only if all modules return <0. Otherwise we do the obvious thing: setxattr, return 0. getxattr: do we return the first nonzero and stop there, or do we return a concatenation of the results? I assume the former...
thanks, -serge - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |