On Thu, 2008-02-28 at 12:20 +1100, James Morris wrote:
quoted text
> On Wed, 27 Feb 2008, David P. Quigley wrote:
> 
> > +int inode_setsecurity(struct inode *inode, struct iattr *attr)
> > +{
> > +	const char *suffix = security_maclabel_getname() 
> > +				+ XATTR_SECURITY_PREFIX_LEN;
> > +	int error;
> > +
> > +	if (!attr->ia_valid & ATTR_SECURITY_LABEL)
> > +		return -EINVAL;
> 
> Do you mean:
> 
> 	if (!(attr->ia_valid & ATTR_SECURITY_LABEL))
> 
> ?

Yep that is what it should be.

quoted text
> 
> >  			mode &= ~S_ISGID;
> >  		inode->i_mode = mode;
> >  	}
> > +#ifdef CONFIG_SECURITY
> > +	if (ia_valid & ATTR_SECURITY_LABEL)
> > +		inode_setsecurity(inode, attr);
> > +#endif
> 
> You're not checking the return value of inode_setsecurity().
> 
> Why not just rely on inode_setsecurity() to perform the check, then you 
> can lose the #ifdefs in the core code & make it a noop for 
> !CONFIG_SECURITY.

I'm not clear as to what you are suggesting here. are you saying put the
#ifdef CONFIG_SECURITY around inode_setsecurity and make the case where
CONFIG_SECURITY isn't set an empty static inline function?

quoted text
> 
> 
> > +#ifdef CONFIG_SECURITY
> > +	if (ia_valid & ATTR_SECURITY_LABEL) {
> > +		char *key = (char *)security_maclabel_getname();
> > +		vfs_setxattr_locked(dentry, key,
> > +			attr->ia_label, attr->ia_label_len, 0);
> > +		/* Avoid calling inode_setsecurity()
> > +		 * via inode_setattr() below
> > +		 */
> > +		attr->ia_valid &= ~ATTR_SECURITY_LABEL;
> > +	}
> > +#endif
> > +
> 
> Similarly, make this a function which is compiled away for 
> !CONFIG_SECURITY.

Same as above.

quoted text
> 
> > +		if (!error) {
> > +#ifdef CONFIG_SECURITY
> > +			fsnotify_change(dentry, ATTR_SECURITY_LABEL);
> > +#endif
> >  			fsnotify_xattr(dentry);
> 
> Put the #ifdef inside fsnotify_change() and only process 
> ATTR_SECURITY_LABEL if CONFIG_SECURITY.

Will do.

quoted text
> 
> 
> > +#ifdef CONFIG_SECURITY
> > +#define ATTR_SECURITY_LABEL  65536
> > +#endif
> 
> I don't think there's any harm in always defining this.
> 
> 

--
unsubscribe notice
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/