question on <auth> and .dbus_keyrings

[Havoc Pennington]

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

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

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.

Havoc