A common VFS and a Common conf-system (Was: namespacing)

[Sean Middleditch]

Jamie McCracken wrote:

> Avery Pennarun wrote:
>
>> On Tue, Mar 01, 2005 at 11:43:58AM -0500, Sean Middleditch wrote:
>>
>>
>>>>> Unfortunately, it's Linux only, and has an incredibly brain-dead 
>>>>> design
>>>>> where you have to utilize "round-trips" through the kernel for
>>>>> something that essentially happens entirely in user-space,
>>>>
>>>>
>>>> This is not entirely true: thanks to some contributions by my company,
>>>> FUSE has extensions that allow the kernel to *cache* your stuff in the
>>>> normal page cache, so after the first access, files can be 
>>>> retrieved as
>>>> quickly as from a normal filesystem, even across processes, and with a
>>>> high level of reliability.  That's a very big advantage that you will
>>>> simply never achieve in a 100% userspace solution.
>>>
>>>
>>> Why can't it be done in userspace?
>>
>>
>>
>> For the same reasons that microkernels are slow.  I don't think I 
>> want to be
>> part of *that* famous argument, so I'll leave it at that :)
>>
>> If all you're doing is opening a word document, I suppose nobody 
>> cares how
>> slow it is (which is why kioslave and gnome-vfs, both awfully slow 
>> systems
>> compared to the kernel, are accepted and useful).  But please don't 
>> ask me
>> to compile my openoffice source tree on such a filesystem.
>>
> True but what beats me if why the common VFS needs to be out of 
> process? (that in itself will kill any hope of it being super fast 
> like FUSE and while I understand Sean's security concerns I dont see 
> it as making much difference - any malicious app can pop up a dialog 
> (or spoof the keyring one) to ask for a password  and fool a user into 
> giving it)

First, you are assuming that all users are "spoofable."  Saying that 
"all users are easy to spoof because most are" results in those of us 
that are in fact capable of realizing that the dialog is forged (we 
didn't do anything that would initiate a password request) would get 
screwed because the system is designed for the LCD of user capability.

Second, while it is currently possible to spoof password dialogs, that 
may not always be the case - in fact, I expect it to stop being the case 
before too long.  There has been a lot of talk about secure X extensions 
for handling this situation; something along the line of what Windows 
does for its login screen.  The ctrl-alt-del key sequence is caught by 
the kernel and never ever passed on to an application unless it has 
special privileges.  X can be such a process.  When the key sequence is 
pressed, something can be done to show the user whether the password 
prompt is legit or not; for example, when the key sequence is pressed, 
all windows from processes without the password prompt privilege could 
be minimized, or the prompt window could flash red if it has privileges 
- that can't be spoofed since the app won't know that you hit 
ctrl-alt-del due to the special handling.

Furthermore, the daemon will *not* result in noticable speed 
degradation.  You might as well try to convince people that X is broken 
and unusable because it uses a daemon instead of having all applications 
draw directly to the framebuffer...

And, as I noted, the VFS API doesn't FORCE a daemon, so if you really do 
have immense fears about getting every last possible drop of performance 
out of the system, you would be completely and absolutely able to just 
ignore the daemon, and deal with the consequences (insecurity) as you wish.


>
> jamie.
>
>> Have fun,
>>
>> Avery
>> _______________________________________________
>> xdg mailing list
>> xdg at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/xdg
>>
>>
>
>