Re: reiser4 plugins

[David Masover <ninja@slaphack.com>]

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