[Bug 75602]

[Krzysztof-konopko]

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.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to dbus in Ubuntu.
https://bugs.launchpad.net/bugs/75602

Title:
  DBUS Should Support "Session Groups"
  (pam_group.so,/etc/security/groups.conf)

Status in D-Bus:
  In Progress
Status in “dbus” package in Ubuntu:
  Triaged

Bug description:
  Binary package hint: dbus

  In my lab, there are lots of users in an LDAP database. These users
  are assigned to the groups audio,video,plugdev,etc. by pam_group
  (using the /etc/security/groups.conf file). The problem is, DBUS
  doesn't recognize users as being in groups unless they're in
  /etc/group, which isn't practical for our setup. So, there are
  permission problems with USB sticks, kpowersave, etc. (well, there
  *will* be, once I upgrade from Dapper to a more version of Kubuntu).

  On my laptop, I can use (the kludge) "adduser $uname plugdev"... this
  won't work in the lab.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dbus/+bug/75602/+subscriptions