DBUS_TYPE_LINUX_CRED ?

[Lennart Poettering]

On Fri, 13.12.13 21:17, Serge Hallyn (serge.hallyn at ubuntu.com) wrote:

> > Also, why even, you can easily implement that on top of D-Bus without
> > hacking it into pieces. For example, if the sender wants to send the
> 
> I don't think D-Bus would need to be hacked to pieces.  Just another
> message data type.  Patch to dbus should actually be quite small, but
> given my unfamiliarity with dbus I thought I'd ask first to see if the
> patch would even be welcome.

Well, but it won't stay like that.. I mean, if you start with PIDs, and
UIDs, then people want GIDs, and audit session uids, and auxiliary gids,
then cgroups memberships, yadda yadda. And we certainly don't want all
of those as high-level data types.

> > identity of some process to somebody else, make the sender
> > get itself a AF_UNIX/SOCK_DGRAM socket pair via socketpair(), and send
> > an empty datagram with the SCM_CREDENTIALS of your choice into the
> > writing side, then close that. And send the reading side over the bus as
> > file handler use the dbus "h" type. Then also close the reading
> > side. The receiver can then read the datagram out of it, with the creds
> > translated and then closes it.
> 
> Yup, that's certainly a possibility.  But a simple
> 
> 	struct ucred cred = { .pid = pid, .uid = uid, .gid = gid};
> 	dbus_message_iter_append(basic (&iter, DBUS_TYPE_LINUX_CRED, &cred)
> 
> would have been much nicer, so I thought it worth asking.  But if it's
> not desired in dbus, then I'll certainly respect that.  Thanks for your
> time.

Well, I am hardly the D-Bus maintainer these days, I cannot make these
decisions. But from my perspective this sounds waaaaay too specific to
make this a high-level dbus data type, especially if there's a
relatively easy way to do things without. 

Also note that there are some influental people who really didn't like
the addition of file handles as data type to dbus. But sending file
handles is certainly an "enabler". However, sending translatable creds
is not an enabler, you can already do this now by using the file handle
stuff.

> PS
> I realize I'm one of or the first to ask for this, but I suspect now
> that unprivileged users can unshare to their hearts' content due to
> unprivileged unshare(CLONE_NEWUSER) followed by clone(CLONE_NEWPID),
> it will become a more common request.  Things like /proc/$$/vpid
> have been rejected in part due to scm_creds existing;  passing a
> /proc/$$ or /proc/$$/status does not help since its contents are not
> translated for the reader, but rather by superblock;  so sending an

Well, that this isn't translated while reading is sad.

I'd certainly enjoy it if we could get fds to processes by opening
/proc/$PID, and then get translated access to its properties, and best
would even be if we get a POLLHUP or so when the process dies... And if
the exit status would be retrievable via /proc/$PID, too, and the PID
not released until the last fd to it is closed. If we had that then we
suddenly would have a useful identifier for a process that is not
subject to reuse, that is race-free and quite comprehensive, and nobody
would have to deal anymore with that awful nonsense that is wait()...

> scm_cred or doing "setns target_pid; unshare mntns; mount /proc; look
> around" are the only two ways of really doing something like this.

That mount /proc trick is even uglier than the scm_creds thing...

Lennart

-- 
Lennart Poettering, Red Hat