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
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
