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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4/19/05, Bodo Eggert <[email protected]> wrote:
> >
> > Well, that would kinda be the intent behind the permissions file  --
> > it can specify what restricted set of images/devices/whatever the user
> > can mount, I suppose the sensible thing would be to always enforce
> > nosuid and nsgid, but I'd rather keep these as the default version of
> > options (allowing admins to shoot themselves in the foot perhaps, but
> > in the single-user workstation case, is seems like there's less reason
> > to be so paranoid).
> 
> I think you shouldn't help the admins by creating shoes with target marks.
>

Fair enough.  Since I don't really have any cases I can think of that
require this sort of behavior, I'll back off on allowing user mounts
with suid or sgid enabled.

> 
> Allowing user mounts with no* should be allways ok (no config needed
> besides the ulimit), and mounting specified files to defined locations
> is allready supported by fstab.
>

Do folks think that the limits should be per-user or per-process for
user-mounts, what about separate limits for # of private namespaces
and # of mounts?

The fstab support doesn't seem to provide enough flexibility for
certain situations, say I want to support mounting any remote file
system, as long as its in the user's private hierarchy?   What if I
want user's to be able to mount FUSE, v9fs, etc. user-space file
systems, but only in a private namespace and only in their private
hierarchy?  Or are these situations which you think should "always be
okay" as long as nosuid and nogid (and newns?) are implicit?

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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux