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

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Mo, 28.11.22 00:14, Dominik George (nik@xxxxxxxxxxxxx) wrote:
65;6800;1c
> Hi,
>
> > The approach brings me a bit farther away from being able to implement it myself, but not too far I guess ;).
>
> I've spent some time reading the userdb code now, and it actually
> seems pretty easy to do.
>
> Here's my rough plan:
>
>  1. In src/userdb/userdbd-manager.c manager_startup(), set teh
>     SO_PASSCRED socket option
>  2. In src/shared/varlink.c, change the behaviour in two places:
>      - In varlink_read, use recvmsg to read the SCM_CREDENTIALS
>        message and, if we get one and its uid is valid, store the
>        ucred in the varlink struct and set its ucred_acquired to truw
>      - In varlink_write, always send an SCM_CREDENTIALS message —
>        if ucred_acquired is true on the varlink object, send this
>        ucred struct' if it is false, send an empty message to use
>        our real credentials

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.

> Given that all userdbd services in systemd, including the multiplexer,
> use the same code, this should be all there is to it to enable the
> discussed behaviour in systemd, and downstream service implementations
> could start using it.
>
> If yhere is nothing fundamentally wrong with my assessment, I'll give
> the implementation a shot.

Sounds great! Happy to review a PR for that.

In the varlink API please report the SCM_CREDENTIALS ucred seperately
from the SO_PEERCRED though (i.e. from the current ucreds we already
store). For various purposes it is interesting to know the identity of
the process initiating the connection, if it's different from the
process actually sending messages over it.

Lennart

--
Lennart Poettering, Berlin