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

Re: FUSE merging?



Anton Altaparmakov <aia21@cam.ac.uk> wrote:
>
> On Thu, 2005-06-30 at 12:20 +0200, Arjan van de Ven wrote:
> > On Thu, 2005-06-30 at 12:12 +0200, Miklos Szeredi wrote:
> > > > if you are so interested in getting fuse merged... why not merge it
> > > > first with the security stuff removed entirely. And then start
> > > > discussing putting security stuff back in ?
> > > 
> > >   a) it's already been discussed to death (just search for 'fuse' on
> > >      lkml and fsdevel)
> > > 
> > >   b) I don't consider it a good idea to ship a defunct version of it in
> > >      the mainline
> > > 
> > > Can you please accept my wish to have FUSE merged _with_ the
> > > unprivileged mount's thing.
> > 
> > By the same argument:
> > Then can you please accept that FUSE will not get merged right now.
> 
> Why should he?  IMNSHO it should be merged right now with the security
> stuff.  FUSE works as is.  Without the security stuff FUSE is useless.
> 
> I have yet to read even a single constructive argument why it should not
> be merged as is.

I believe that the requirement which fuse_allow_task() attempts to satisfy
is legitimate and is useful to FUSE users.

The fact that, AFAIK, nobody as found a way to implement it more nicely is
a Linux problem, not a FUSE problem.

Given that the actual amount of code involved is small, centralised and
well known about we can easily fix it up later if/when new infrastructure
or new ideas become available.

So unless someone is able to come up with a better approach in the next few
days I'm inclined to say "we suck" and merge the thing as-is.

However, a few things:

- is there anything in the current implementation of the permission stuff
  which might tie our hands if it is later reimplemented?  IOW: does the
  current FUSE user interface in any way lock us into the current FUSE
  implementation (fuse_allow_task())?

- the fuse mount options don't seem to be documented

- aren't we going to remove the nfs semi-server feature?

- Frank points out that a user can send a sigstop to his own setuid(0)
  task and he intimates that this could cause DoS problems with FUSE.  More
  details needed please?

- I don't recall seeing an exhaustive investigation of how an
  unprivileged user could use a FUSE mount to implement DoS attacks against
  other users or against root.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Submit]     [Site Home]     [Kernel Newbies]     [Memory]     [Consulting]     [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