Re: RFC: Passing on initial client user in systemd-userdbd

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Mo, 28.11.22 16:27, Dominik George (nik@xxxxxxxxxxxxx) wrote:

> Hi,
>
> > You don't have to send that really, the kernel will implicitly attach it
> > automatically whenever the sender's credentials change. Thus, a
> > receiver can safely assume that the ucred remains the same as the
> > SO_PEERCRED data until it receives a new SCM_CREDENTIALS that says
> > otherwise.
> >
> > You want to send SCM_CREDENTIALS explicitly only when you actively try
> > to impersonate someone else.
>
> I'm not convinced of that. Of course, sending the creds if it does not
> differ from the process running would be sufficient, but doing it in
> all cases removes a lot of complexity.

>From the receiving side there's very little difference in behaviour:
the kernel will automatically send this stuff *anyway* if needed.

hence on the receiving side in the Varlink object just add a new
"struct ucred" field that stores the last SCM_CREDENTIALS ucred that
was received. Update it whenever a new SCM_CREDENTIALS is received. It
will look the exact same way from the receiving side if on the sending
side the kernel sent it automatically because the sender's uid changed
or if the sender appended it explicitly because it felt like it, for
example because it wants to impersonate someone.

> Sending SCM_CREDENTIALS selectively would mean we would have to
> introduce a distinction between systemd-userdbd acting as multiplexer
> and not doing so, which would require moving quite a bit of code
> around that is now neatly generic.

userdbd should always impersonate the client it received the request
on. What I am saying is that regular varlink client code (i.e. not
userdbd, not an impersonator) should not bother with this at all,
since the kernel well attach this info anyway if needed. Only
impersonators need to attach SCM_CREDENTIALS explicitly, and userdb
should be one of these impersonators.

Lennart

--
Lennart Poettering, Berlin