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

[Miklos Szeredi]

> > 
> >   - global limit on user mounts
> 
> I don't think we need that one.

We have that for open files '/proc/sys/fs/file-max'.  It limits the
total memory usage of the thing.  Which otherwise is hard if you have
a system with lots of users.

> >   - possibly per user limit on mounts
> 
> Makes sense as an ulimit, that way the sysadmin can easily disable the
> user mount feature aswell.
> 
> >   - acceptable mountpoints (unlimited writablity is probably a good minimum)
> 
> Yupp.
> 
> >   - acceptable mount options (nosuid, nodev are obviously not)
> 
> noexecis a bit too much, so the above look good.
> 
> >   - filesystems "safe" to mount by users
> 
> what filesystem do you think is unsafe?
> 
>  - virtual filesystems exporting kernel data are obviously safe as
>    they enforce permissions no matter who mounted them.  (actually we'd
>    need to check for some odd mount options)

Maybe sysadmin doesn't want to let users see /sys for example.  How
would you disable it if users can mount it themselfes?  OK, you can
disable user mounts completely, but that's probably not fine grained
enough for some.

>  - block-based filesystems should be safe as long as the mounter has
>    access to the underlying block device

Not true if user controls the baking device (e.g. loopback).  Most
block based filesystems are probably unsafe at the moment, because not
enough consistency checking is done at runtime.  Are things like
non-cyclic directory graphs ensured by all filesystems?  My guess is
not.  See also Linus' comment about the state of the iso9660
filesystem:

  http://lwn.net/Articles/128744/

>  - network/userspace filesystems should be fine aswell

They should, but again I wonder if NFS with all it's complexity is
being careful enough with what it accepts from the server.

Smbfs might be close to safe, since it's already available for users
to mount from an arbitrary server.

So safeness is a per-filesystem property, determined, how well it
checks input.

Miklos
-
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/