Re: reiser4 plugins

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

 



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