Re: [RFC] FUSE permission modell (Was: fuse review bits)

[Eric Van Hensbergen]

On 4/17/05, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> > >
> > >   1) Only allow mount over a directory for which the user has write
> > >      access (and is not sticky)
> > >
> > >   2) Use nosuid,nodev mount options
> > >
> > > [ parts deleted ]
> >
> > Do these solve all the security concerns with unprivileged mounts, or
> > are there other barriers/concerns?  Should there be ulimit (or rlimit)
> > style restrictions on how many mounts/binds a user is allowed to have
> > to prevent users from abusing mount privs?
> 
> Currently there is a (configurable) global limit for all non-root FUSE
> mounts.  An additional per-user limit would be nice, but from the
> security standpoint it doesn't matter.
> 
> > I was thinking about this a while back and thought having a user-mount
> > permissions file might be the right way to address lots of these
> > issues.  Essentially it would contain information about what
> > users/groups were allowed to mount what sources to what destinations
> > and with what mandatory options.
> 
> I haven't yet seen the need for such a great flexibility.  Debian
> installs fusermount (the FUSE mount utility) "-rwsr-x--- root fuse",

These are both well and good, but I was looking for a more global
system (for things other than FUSE).

> 
> > Is this unnecessary?  Is this not enough?
> 
> Maybe it is necessary, but why bother until somebody actually wants
> it?  I'm a great believer of the "lazy" development philosophy ;)
> 

Yeah, I guess I'm motivated in that I want to use normal mount to
handle v9fs user file systems, local private mounts, and local private
resource shares.  I'd also like normal users to be able to take better
advantage of -o bind.  I think its kinda silly that we have special
purpose mounts for cifs, samba, fuse, v9fs, etc -- but I suppose
that's more of a user-space util-linux dilemma than a kernel dilemma.

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