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