A common VFS and a Common conf-system [Part II]

[Sean Middleditch]

On Thu, 2005-03-03 at 10:00 +0100, Alexander Larsson wrote:
>On Wed, 2005-03-02 at 21:21 -0500, Sean Middleditch wrote:
>> >
>> >The problem is, that there might be lots of third party libraries which 
>> >don't support async io.
>> 
>> It can be worked around on a case-by-case basis.
>> 
>> If SMB does need a separate thread for each connection, that can be
>> done, and it can be completely hidden as an implementation detail of the
>> backend.  It's frustrating that that might have to be the case, but it
>> doesn't really affect the API or other backends at all.
>> 
>> If many/most backends need such a thing, then I guess threaded will be a
>> necessary.  We're way far away from even being at the point where this
>> matters, though - I'm right now concerned about the *application* API,
>> not the internal implementation of the daemon or its backends.
>
>You need threads or external processes for file:/// too, otherwise any
>access to a NFS mount where the server is down hangs all I/O in the
>desktop. Even if the NFS mount isn't totally down you can't do async i/o
>on unix files, which means it'll block the rest of the vfs while doing
>I/O.
>
>I guess you might be able to use posix aio, but I don't think thats very
>portable yet, nor does it support stat or readdir. (Does it still use
>threads on linux?)
>
>Some other issues:
>
>You have to do authentication callbacks in the process doing the actual
>i/o request. Otherwise things like gnome-keyring that depend on which
>binary did the request to decide access rights won't work.

I would argue then that the daemon can forward the information about the
process to the keyring, or that they keyring can tie in better to the
daemon.  My plan was to make the daemon talk to an external helper over
D-BUS (or a more direct protocol if necessary for security - haven't
looked at that in depth yet), so gnome could provide such a helper that
used the keyring.  Making sure that the actual applications never touch
the authentication information is something I'm rather keen on - it
really can eliminate an entire class of security holes and information
leaks.

>
>Authentication caching is a very complicated issue. When do you cache?
>How long do you cache? Is the cache shared between apps (and how does
>this affect security vs ease of use)? How do you log in as someone else
>when you've already logged in?

In a large part this has less to do with the VFS layer and more to do
with the UI built on top of it.  Providing a "fresh session" API would
be possible, but Nautilus (for example) would need to actually provide a
way for the user to indicate that they want to do this.

>
>One thing that makes authentication caching is the connectionless model
>that e.g. gnome-vfs has. We don't know that there is an "active
>connection" to some ftp server (say, nautilus is displaying it), so we
>can't tie cache lifetimes to a connection. On the other hand, we likely
>want to reuse the connection nautilus uses in e.g. gedit if we click on
>a text file in the nautilus window, so we can't tie the connection only
>to nautilus. I think you'd want a higher level object above the file
>access operations, but slightly less than a full connection object.
>
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Alexander Larsson                                            Red Hat, Inc 
>                   alexl at redhat.com    alla at lysator.liu.se 
>He's an obese voodoo dwarf on the wrong side of the law. She's a sarcastic 
>Bolivian traffic cop from Mars. They fight crime! 
>
>
-- 
Sean Middleditch <elanthis at awesomeplay.com>