Comment 21 for bug 75602

Created attachment 76666
Required plumbing for reading process credentials from procfs v. 2

OK, here's another attempt with the PID plumbing :)

This time I tried to focus on EXTERNAL authentication and took your advice from the previous review. My main goal is to avoid touching /etc/{passwd,group} if possible.

Here are the highlights:
- if the data sent along with AUTH message is a numeric UID, then try to use it instead of looking in /etc/passwd.
See handle_server_data_external_mech(). The desired_identity is checked against the UID from the socket so no risk here.

- the next step is determining whether the client can connect
bus_policy_allow_unix_user() takes additionally PID as an argument and tries to get groups from /proc first (_dbus_unix_groups_from_pid() not implemented yet) and falls back to the lookup based on UID.

- a new API function introduced to get the PID form the connection and pass it to client authentication: dbus_connection_get_unix_process_id_unauth()
As opposite to dbus_connection_get_unix_process_id(), it doesn't try to authenticate the user internally which at this stage would end up in the endless loop.

Unfortunately got stuck with bus_policy_create_client_policy()
This function calls _dbus_unix_user_is_at_console() which unfortunately needs a username so ends up looking in /etc/passwd (for UIDs without the entry in /etc/passwd _dbus_user_database_lookup() fails with assertion). Need to think how to avoid touching /etc/passwd here.
The goal here is to let D-Bus find out about the process from it's state (socket credentials, procfs if possible) rather than pesky /etc/passwd. And a natural way of doing it is to try the authentication with UIDs not present in /etc/passwd.
I guess the priority in this bug is to focus on groups. So if I can't come up with something reasonable for the problem above, I'll carry on with groups only.