[systemd-devel] [PATCH][RFC] bus-proxy: add support for "GetConnectionCredentials" method
Simon McVittie
simon.mcvittie at collabora.co.uk
Thu Feb 19 05:05:22 PST 2015
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/>
More information about the systemd-devel
mailing list