[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