Re: [PATCH] cifs: handle termination of cifs oplockd kernel thread

[Steve French]

On Sat, 2005-04-30 at 03:29, Christoph Hellwig wrote:
> > 
> > Having a mount owner is not a problem.
Perhaps some day "mount owner" might be more complex than simply the
uid_t of the owner (I don't know if there will be future cases in which
you might want to check the gid_t at mount time or some SELinux specific
security context), but I would prefer that mnt_uid be stored in the
superblock so I could get rid of those few lines of code in cifs, and
that is a fairly non-controversial start.   Coming up with the policy
as Miklos and Christoph were suggesting may be doable in small stages.

>   Having a good policy for
> > accepting mounts is rather more so, according to some:
> > 
> >    http://marc.theaimsgroup.com/?l=linux-kernel&m=107705608603071&w=2
> > 
> > Just a little taste of what that policy would involve:
> > 
> >   - global limit on user mounts
> 
> I don't think we need that one.

agreed

> 
> >   - possibly per user limit on mounts
> 
> Makes sense as an ulimit, that way the sysadmin can easily disable the
> user mount feature aswell.
> 

agreed.

> >   - acceptable mountpoints (unlimited writablity is probably a good minimum)
> 
> Yupp.
Yes, although not sure what unlimited means here since the filesystem
you are mounting will often forbid writes (at the server)

> 
> >   - acceptable mount options (nosuid, nodev are obviously not)
> 
> noexecis a bit too much, so the above look good.

There are cases in which adding noexec might make sense as a system
policy for user mounts, but the typical case in which user mounts are
needed are for home directories over the network or equivalent in which
noexec makes it tough for them to be very useful.  nosuid and nodev on
the other hand should be restricted and users are used to this already
since they are the two flags that are added by mount.cifs if a non-root
user mounts and the admin has configured mount.cifs to allow user
mounts, so that would be consistent.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/