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

[Sean Middleditch]

On Thu, 2005-03-03 at 14:11 +0000, Jamie McCracken wrote:
>Alexander Larsson wrote:
>
>> 
>> 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.
>> 
>
>So this kills off the need to have a daemon then?

Woah... not at all!

>
>If so can I reshape Sean's proposals as follows:
>
>We make it fully in process.
>
>We have a libDVFS that provides both async and sync i/o for all backends 
>and also handles any authentication (if this needs to be shared amongst 
>apps then another daemon may be required or maybe the keyring can handle 
>sharing seeing as it will know which apps are authorised to do so).

Providing asynchronous behaviour if we require threading will be a *lot*
easier to do in a separate daemon than in the dvfs library, for one.  It
also makes it easier to make the API easier to use from a threaded
program.

Second, there's still also the security issue of applications having
access to your authentication information.  I'm very firm on this issue
- if we're going to get a new system, we should design it from the very
beginning to make sure that it is friendly with both current and future
security technologies.  Using a daemon can and will completely
obliterate an entire class of potential security problems from malicious
or buggy applications, especially once things like SELinux or TrustedBSD
are in more common use.

>
>The lib will support two kinds of backends - async and sync ones. This 
>should make it very easy to write them whilst being optimal too. The lib 
>will provide all the threading to make sync backends asscesible in an 
>async manner and likewise make async backends synchronous if needs be etc.
>
>For added security (if its really necessary) the backends might need to 
>be digitally signed somehow - the lib should be able to crosscheck with 
>an approved list.

That's something that should probably be punted until the system itself
has better support for signed libraries and applications.  In the short
term, secured machines can simply refuse to load user-installed
backends.  If malicious software can trick the user into installing it
into the system, it doesn't need to corrupt a backend - it could just
modify the daemon directly; software installation is the ultimate gate
to compromised security.

>
>jamie.
>_______________________________________________
>xdg mailing list
>xdg at lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/xdg
>
-- 
Sean Middleditch <elanthis at awesomeplay.com>