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

Sean Middleditch elanthis at awesomeplay.com
Thu Mar 3 19:34:38 EET 2005

On Thu, 2005-03-03 at 18:02 +0100, Alexander Larsson wrote:
>On Thu, 2005-03-03 at 11:55 -0500, Sean Middleditch wrote:
>> On Thu, 2005-03-03 at 17:52 +0100, Alexander Larsson wrote:
>> >> I fully admit to being rather ignorant on the SELinux development
>> >> interface, but that sort of behavior is possible, is it not?  Would it
>> >> also be possible to make the daemon utilize the client application's
>> >> context for file access (similar to the fsuid in Linux) ?
>> >
>> >I know you can pass around selinux contexts. I'm not sure you can do i/o
>> >in a specific context though. I don't really know much about selinux.
>> Guess I'll have to start doing some major reading on it, then.  :)
>For one, its unlikely that the vfs daemon could run something in a
>context that had more priviledges than the original context the daemon
>was running in.

One would assume that the daemon's context would be given the largest
amount of privileges the administrator feels the user should ever have,
and then trust the daemon to restrict those privileges as appropriate
for various apps.

I'm thinking that, preferably, the daemon would be started at login and
remain running during the entirety of the desktop session.  When its not
handling any active server sessions it would ideally be pretty
low-weight in resources, so it shouldn't be an issue.  It could also be
started on-demand by applications that need it when it isn't running,
but I'm under the impression that SELinux makes it possible to handle
this be specifying the allowed context shifts as necessary.

> Alexander Larsson                                            Red Hat, Inc 
>                   alexl at redhat.com    alla at lysator.liu.se 
>He's a Nobel prize-winning chivalrous gentleman spy whom everyone believes is 
>mad. She's a brilliant hip-hop socialite prone to fits of savage, blood-crazed 
>rage. They fight crime! 
Sean Middleditch <elanthis at awesomeplay.com>

More information about the xdg mailing list