question on <auth> and .dbus_keyrings
hp at redhat.com
Wed Jun 28 06:35:54 PDT 2006
Thiago Macieira wrote:
>> I think this is perhaps a nicer and more general approach than just
>> hardcoding "root is OK" - though allowing root doesn't really decrease
>> security in my mind (root could just su to your account, obviously), it
>> also doesn't "solve for good" this issue.
>> This could be done by just adding another auth mechanism.
> Before adding yet another auth mechanism, I'd like to explore the existing
> ones better. I have found very little documentation. Where can I read
> more about them? And are they still subject to the "root-or-user" rule?
I don't know if they have much in the way of docs. If I kept the "auth
script" stuff in the test suite (I'm not sure I did) it has some good
I can summarize briefly. First is that auth means "proving your
identity" not "proving you are allowed to connect" - the "allowed to
connect" part is determined by the dbus server in question based on the
identity. For the bus daemon, it uses a policy in the config file for that.
So the root-or-user policy doesn't really apply to the auth process,
it's a bus-specific thing.
There are two auth mechanisms right now:
- EXTERNAL - reads credentials from UNIX domain socket.
- DBUS_COOKIE_SHA1 (or something like that) - proves you can read a
0600-permissions cookie file from the identity's homedir, and takes
that as proof you are that identity. The cookie file is written out
by the server, and then the client has to read it and provide the
I just remembered there was this whole theoretical support for SASL here
that hasn't been implemented... there was an intent to have the above
two mechanisms built-in, and then support Cyrus SASL as a compile-time
option. But I never got far enough on that to even see if it was feasible.
I think the address format in the env variable already supports
key-value pairs, so to add another auth mechanism using that you could
just add a new key-value maybe. Or two new; one would be the uid that
set the env variable cookie (which you'd prove you were) and the other
would be the cookie itself. Or something.
More information about the dbus