Accessing Session Bus through the superuser

[Thiago Macieira]

Avery Pennarun wrote:
>On Mon, Mar 17, 2008 at 4:59 PM, Thiago Macieira <thiago at kde.org> wrote:
>> Avery Pennarun wrote:
>>  >This is true of any temporary file used by any program.  It's simple
>>  >to just delete the file next time the program starts.
>>
>>  You forgot that the session bus's socket is a random name. The next
>> time it runs, it won't know of the old name. So it won't remove.
>>
>>  So they always accumulate.
>
>But this is only a problem because they use a random name, which was a
>decision made for other reasons that appear not to be actually valid
>after all.  If the sockets used a non-random name (like every other
>unix-domain socket on my entire system), this would not be a problem.
>(As a bonus, we might not need to track down a funny environment
>variable to reach the session bus.)

A constant name would not allow for several sessions running by a single 
user, or many users.

So that idea is discarded right away.

And no, not all applications use constant socket names. KDE uses random 
names for its sockets too -- concrete sockets. The result is many 
left-over sockets lying around for various reasons.

>>  >It's easy to tell if a socket file is still in use or not by trying
>>  > to connect to it: if the listener is dead, you get ECONNREFUSED, so
>>  > it's safe to delete the file.  (There is a slight race condition
>>  > here if you're not careful, if multiple copies of the daemon are
>>  > started simultaneously.)
>>
>>  Moot point.
>
>Unless we resolve the above issue.

Which, like I exposed, cannot be resolved. The name must be random. Or, at 
the very least, variable.

>>  >This was news to me so I checked to make sure: at least on Linux
>>  > 2.6, NFS-mounted folders *can* contain unix domain sockets.
>>
>>  The fact that your Linux NFS client allows sockets doesn't mean the
>> NFS server does. Or if you're not using a Unix-style filesystem for
>> your home (I know some people use SMB for their homes; questionable,
>> but still exists).
>
>If I'm using a screwball filesystem for my home directory, all sorts
>of things will break, including Evolution, Maildir, anything that uses
>sqlite, anything that uses chmod, anything that uses a symlink, and so
>on.  I'm not sure dbus should cater to this (seemingly a bit
>imaginary) case.  If someone is crazy enough to use an SMB-mounted
>homedir, they can always override dbus's standard socket location too.

KDE runs on SMB filesystems. And KDE is many orders of magnitude more 
complex than D-Bus, so D-Bus should too.

It's not an imaginary case: I remember many fixes going in because of 
missing features on those sucky filesystems, from the inability to delete 
an opened file (used for atomic file saving) or simply some characters 
not being allowed in the file name.

>>  >The session bus actually implements a completely different third
>>  >security policy using a third type of socket.
>>
>>  And on Windows it uses named pipes instead of sockets.
>
>...where it presumably uses either no authentication, kernel-level
>security, or magic-cookie authentication, any of which would solve the
>problem that started this thread. It certainly doesn't use Unix-style
>credential passing.

I have no idea what kind of authentication it uses, if any at all.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/dbus/attachments/20080317/0dc5784f/attachment.pgp