Accessing Session Bus through the superuser

[Avery Pennarun]

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

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

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

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

Have fun,

Avery