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

[Jamie McCracken]

Sean Middleditch wrote:
> 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.

That wasn't my assumption at all. Security conscious users would of 
course only install digitally signed apps from trusted parties so this 
entire issue for them at least would be (or should be) irrelevant.

Apps that do actually need passwords can be malicious too so even expert 
users can get caught. Its folly to be complacent with security and 
digital signing seems to be the most foolproof method we can use.

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

That would be very useful.

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

I assumed the very poor performance of Gnome-vfs was mostly due to it 
being out of process (and possibly it being Corba related too).

Dbus according to Havoc will be at least 4x slower than using a socket 
so I am slightly concerned that a Dbus based VFS might suck performance 
wise.

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

okay thats fine. If we have a choice then that should keep everyone happy.

jamie.