On 19/02/15 12:43, Lukasz Skalski wrote:
GetConnectionCredentials method was added to dbus-1 specification
more than one year ago. This method should return "[...] as many
credentials as possible for the process connected to the server",
but at this moment only "UnixUserID" and "ProcessID" are defined
by the specification. We should add support for next credentials
after extending dbus-1 spec.

As of dbus master (soon to be 1.9.12), LinuxSecurityLabel is also defined. It's the bytestring from SO_PEERSEC, whatever that means for the current LSM(s), with a trailing '\0' appended if there wasn't already one there. AppArmor, SELinux and Smack developers have all told me this is valid for their LSMs.

Spec patches welcome for others, but I don't think there's a great deal of point in adding GetConnectionCredentials support for additional credentials that can be transferred over kdbus but not (securely) over AF_UNIX: anything with enough kdbus knowledge to know about those might as well be using kdbus directly.

+                r = get_creds_by_message(a, m, SD_BUS_CREDS_PID|SD_BUS_CREDS_EUID, 
&creds, &error);

Can this ever return "unknown" (-1?) for creds->pid or creds->euid? If it can, then ProcessID and UnixUserID should be omitted from the map when that happens, instead of being included with a dummy value.

+                r = sd_bus_message_append(reply, "{sv}", "ProcessID", "u", 
(uint32_t) creds->pid);

If the pid is out of range for uint32 it should be omitted from the map (although that can't actually happen on current Linux). Same for the uid.

--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>

_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to