DBUS_TYPE_LINUX_CRED ?

[Serge Hallyn]

Quoting Lennart Poettering (mzqohf at 0pointer.de):
> On Fri, 13.12.13 15:58, Serge Hallyn (serge.hallyn at ubuntu.com) wrote:
> 
> > 
> > Quoting Thiago Macieira (thiago at kde.org):
> > > On sexta-feira, 13 de dezembro de 2013 15:53:26, Serge Hallyn wrote:
> > > > Quoting Thiago Macieira (thiago at kde.org):
> > > > > On sexta-feira, 13 de dezembro de 2013 14:19:14, Serge Hallyn wrote:
> > > > > > > I am pretty sure it would be wrong to have something like this as data
> > > > > > > type. This data should be appended implicitly, not explicitly.
> > > > > 
> > > > > So it should send them all, like Lennart said that kdbus is already doing.
> > > > 
> > > > Send all of what?
> > > 
> > > All of the credentials.
> > > 
> > > He said: "In kdbus you will also get a variety of creds attached to all 
> > > messages implicitly (pid, gid, uid, pid_starttime, tid, comm, tid_comm, 
> > > cmdline, cgroup, unit, slice, user unit, session, owner uid, eff caps, inh 
> > > caps, perm caps, bounding caps, selinux context, audit session, audit login
> > > uid)"
> > > 
> > > > > > It can't be done implicitly, though, since dbus doesn't know which
> > > > > > ucred I want to send.  I'm not authenticating as that task, I just need
> > > > > > an unambiguous namespace-independent identifier for it.
> > > > > 
> > > > > Use the unique connection ID.
> > > > 
> > > > an unambiguous namespace-independent identifier for a task not involved
> > > > in the connection.
> > > 
> > 
> > Sorry, I think I'm failing to make myself clear.
> > 
> > > The task is involved in the connection since it's sending data in the first 
> > > place.
> > 
> > That task, c, is making a request involving another task, v.  It is v's
> > pid which needs to be sent with an scm_cred so the kernel can translate
> > it to the server's namespace.
> 
> So you want to attach fake SCM_CREDS to messages to send over the bus so
> that the kernel will do the translation for you? That sounds a highly
> specialist operation and is really nothing that D-Bus should take care
> of.
> 
> 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.

> 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.

thanks,
-serge

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
scm_cred or doing "setns target_pid; unshare mntns; mount /proc; look
around" are the only two ways of really doing something like this.