On Thu, Feb 19, 2015 at 05:44:34PM +0100, Djalal Harouni wrote: > On Thu, Feb 19, 2015 at 01:05:22PM +0000, Simon McVittie wrote: > > 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? > So, I'm missing lot of bits, but pid can be 0, euid can perhaps be > (uid_t)-1 which is also a valid value... that maps to the INVALID_UID btw you will hit this when you cross pid and user namespaces, and it depends on the process receiving the creds if it has the rights to read or map these fields, which may be the case of modern containers...
-- Djalal Harouni http://opendz.org _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
