On Wed, 2008-03-05 at 13:25 -0500, Trond Myklebust wrote:
> On Wed, 2008-03-05 at 10:31 -0500, Eric Paris wrote:
> > @@ -1214,6 +1232,32 @@ static int nfs_validate_mount_data(void *options,
> > args->namlen = data->namlen;
> > args->bsize = data->bsize;
> > args->auth_flavors[0] = data->pseudoflavor;
> > +
> > + /*
> > + * The legacy version 6 binary mount data from userspace has a
> > + * field used only to transport selinux information into the
> > + * the kernel. To continue to support that functionality we
> > + * have a touch of selinux knowledge here in the NFS code. The
> > + * userspace code converted context=blah to just blah so we are
> > + * converting back to the full string selinux understands.
> > + */
> > + if (data->context[0]){
> > +#ifdef CONFIG_SECURITY_SELINUX
> > + int rc;
> > + char *opts_str = kmalloc(sizeof(data->context) + 8, GFP_KERNEL);
> > + if (!opts_str)
> > + return -ENOMEM;
> > + strcpy(opts_str, "context=");
> > + strcat(opts_str, &data->context[0]);
>
> Shouldn't this be a strncat? I can't see that we're sanity checking the
> data->context string for \NUL termination anywhere.
No good reason not to make sure since we know the size of the static
context array. I just assumed NFS was doing checks on the hostname and
the context array the same way to make sure they were both valid. I'll
send a new patch which uses strncat.
> > + rc = security_sb_parse_opts_str(opts_str, &args->lsm_opts);
> > + kfree(opts_str);
> > + if (rc)
> > + return rc;
> > +#else
> > + return -EINVAL;
>
> Is this really necessary?
If someone used context= with the binary data interface the kernel needs
to tell them that it didn't understand. It's really no different than
nfs_parse_mount_options() having the out_unknown error case instead of
just ignoring unknown. If they used the text interface they would fail
on the out_unknown case if !CONFIG_SELINUX.
> > +#endif
> > + }
> > +
> > break;
> > default: {
> > unsigned int len;
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
