Messages in this thread | | | Date | Mon, 27 Jun 2005 16:19:21 -0500 | From | David Masover <> | Subject | Re: reiser4 plugins |
| |
-----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/
| |