Re: -mm -> 2.6.13 merge status (fuse)

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

 



> > So I welcome constructive discussion.  However bear in mind, that I
> > definitely don't want to disable unprivileged mounts.  For me that is
> > _the_ most important feature of FUSE.
> 
> If the choice was "merge FUSE without unpriv mounts for now" or "discard
> fuse completely" which is preferable.

FUSE is doing fine outside mainline, so discard wouldn't be such a big
setback.  Including it without unpriv mounts would effectively fork
FUSE into an out-of-tree and an in-tree version, which is sure to
cause confusion.

So yes, I'd prefer not merging to merging without unpriv mounts.  But
it's GPL, so obviously I don't have any legal control over it.

> It seems to me (just IMHO) that it would be better to merge FUSE without
> that feature and then spend the time getting that feature right _in
> parallel_ with people using, breaking and reviewing FUSE a lot more.

The security measure in question is actually very simple (10 lines or
so).  So it's not the implementation that people have problems with
but the concept.  The concept itself is hard to swallow, because it
does something unexpected, but what it does is in fact very logical.

That's why I ask people to read the documentation, think about it and
_then_ argue.  Up till now the discussion with Christoph Hellwig about
this hasn't been on the level of rational arguments (and he's the only
definite naysayer).

Thanks,
Miklos
-
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