Re: reiser4 plugins

[Kyle Moffett]

On Jun 26, 2005, at 23:24:23, David Masover wrote:
> > Neither do I want the kernel to unzip it, because that just   
> > introduces the
> > kernel to a whole series of normally application-level  
> > vulnerabilities.
>
> That just means the zip plugin has to be more carefully written than I
> thought.  It would have to be sandboxed and limited to prevent buffer
> overruns and zip bombs.



> Remember that zip, at least, would not be in the kernel.  I think what
> is going in the kernel is gzip and lzo, and it's being done so
> transparently that you never actually see the compressed version.


> > Can you illustrate for me with precise, clear, and unambiguous  
> > arguments
>
> That will take some time.  And some thinking.

Precisely.  Come back when you have a good sturdy set of arguments.  See
the FUSE project (Also discussed in this thread), for better ideas on  
how
to add strange filesystem semantics.  NOTE:  Even the FUSE project,  
which
is in _userspace_ (as opposed to the massive kernelspace mess of  
reiser4),
is taking a lot of flak for changing UNIX semantics, so I see no reason
why Reiser4 should be special.

> > how this can avoid all possible pitfalls,
>
> Especially if you want perfection.

It doesn't need perfection, it just needs to convince a large segment of
the developers on this list (and especially linus).

> > including the automatic encryption/decryption and most other non-  
> > standard
> > filesystem features (Basically the whole '...' directory), should   
> > probably
> > be left out of any patch submitted for inclusion until they can be
> > _proven_ (or at least thoroughly checked) not to have undesirable  
> > results.
>
> I am doing that out of habit.  Actually, it probably ends up more as:
>   .../foo.zip/
> instead of
>   foo.zip/.../
>
> But, it is left out.  At least that interface.

Ok, good.  That's one of the first issues.  A _lot_ of applications  
would get
themselves thoroughly confused at that '...' interface, not to  
mention a lot
of sysadmins :-D.

> Now, the cryptocompress as it currently stands does not involve ...  
> and
> does not introduce any new security holes in the way that you are
> describing.

Good.  I think that we can all agree that, in the event  
cryptocompress is
included, it would be a nice feature to have in all filesystems.   
Therefore,
we should attempt to come up with a clean interface with which it  
could be
added _inside_ the VFS.

> There might be some issues with key management (someone
> hinted vaguely at that), but nothing insurmountable.

Likewise, this should be handled in a common VFS interface that all FSs
can use.  There already exists a key management system that would not be
particularly difficult to interface with, but it would take thought and
discussion.

Cheers,
Kyle Moffett

--
There are two ways of constructing a software design. One way is to  
make it so simple that there are obviously no deficiencies. And the  
other way is to make it so complicated that there are no obvious  
deficiencies.
 -- C.A.R. Hoare

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