Re: reiser4 plugins

David Masover
2005-06-27T21:22:16Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kyle Moffett wrote:
> 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.

If I didn't care about performance. I will read up on how FUSE works,
though, to see if there's anything in the _kernel_ code that would be
useful.

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

Right. Kernel people hate change. Got it.

No, seriously, I have to respect the history involved, which is why I'm
not pretending to know more than I do.

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

Not as much as you think. Unless a lot of applications can't handle
opening or saving files that have '...' in the pathname?

The sysadmin problem doesn't worry me so much.

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

Agreed. I don't know enough about VFS to propose one, though. I think
others are working on that, finally.

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

Not too much, I hope.

Although being able to use different keys on a per-file basis would be
nice. I'm not sure if that would work in the existing system. Not to
mention that keys would also be handlable with '...', if/when it happens.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQsBtWXgHNmZLgCUhAQI5gw/8DXFk/v3faGbAtv0vdeMmy5aZ4MSpr3pp
+rjjb8Wx6twCZelmPQgwTBtSQec9XUEipW3ucHVeP5Y2LM8hZHfbxEpHCzDydlH0
AppxZfHp/FBlqROSYajcc4qX062QQ7Wc/VfePmvVKcC7Plo1n1UnF30RRFLR67/r
SOwb4/GPDnYyY0SQQt8XmuFmu1ngRB5M/kFgGOkiGLOsRiPzx4zVnYsxnOp8vH/q
l0SxCsjev4+dL0TRnFBhx/uw7GerZJhqjjB9DZZgMIXILXt8oTHj1ubEXD0WRQxr
iwiXruO2rO3vFbJVXzdlhFnUj98ViQR9nALa+CwT779Zus9hx8/KAxScPXEZPzVz
jdF7y7GUvBL9vR+t5TTJjlpSqyfiyYKEw038/li/uBB1ThXtjTx4uL0QLzWkaaOh
mfdX5RFwyinrsmscBaYgUPHwqLTjgcIWwqSfmGQ9RvYbMkHy9ZOzHTP9chJIeD5F
cuJPluPEOMpeQduF/S7sG/Y00eQaMx0nBxtDprkwonnhy3Qw2jSSgsXqEIG+x45P
3qjiK7/4cZSkN/Q/VkObEwD0GE2FD31yfqSkrkGRMkhOg22YWBVqrwvmcm2RyQk9
h9S9C3HzNXGAuW9HfCmWLqg1yAQCilkTdGRpc38unBa364nRlBzii7PkA3XLol3S
zChIED+O964=
=shbE
-----END PGP SIGNATURE-----