Hi,
> Just add the capability to the service unit file.
Sure, I can do that.
My doubts are not about how to do it, but whether it is a good idea.
CAP_SYS_ADMIN is a rather huge pile of capabilities, and certainly there is a
reason userdbd runs with a very constrained set now?
-nik
On Di, 29.11.22 11:50, Dominik George (n...@naturalnet.de) wrote:
> Hi,
>
> > in theory, I have implemented that now […]
>
> In practice now, as well:
>
> https://github.com/systemd/systemd/pull/25556
>
> However, something kicked back here a bit… systemd-userdbd drops all
> capabilities, and se
Hi,
> in theory, I have implemented that now […]
In practice now, as well:
https://github.com/systemd/systemd/pull/25556
However, something kicked back here a bit… systemd-userdbd drops all
capabilities, and sending SO_PASSCRED requires CAP_SYS_ADMIN…
What do we do about that?
Cheers,
Nik
Hi,
> in theory, I have implemented that now, but I somehow cannot make
> userdbd send credentials on, because it does not seem to call
> varlink_write at all. I am a bit lost with that, because as I
> understand the code, all parts of userdbd and homed should be using
> varlink_write when calling
Hi Lennart,
in theory, I have implemented that now, but I somehow cannot make
userdbd send credentials on, because it does not seem to call
varlink_write at all. I am a bit lost with that, because as I
understand the code, all parts of userdbd and homed should be using
varlink_write when calling m
On Mo, 28.11.22 16:27, Dominik George (n...@naturalnet.de) 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_PE
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.
>
On Mo, 28.11.22 00:14, Dominik George (n...@naturalnet.de) 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
> 1. In src/userdb/userdbd-manager.c manager_startup(), set teh
> SO_PASSCRED socket option
OK, correct that: We need to set the option on the new fd from accept() instead.
-nik
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
Hi Lennart,
thanks for your once again fast, yet very thoughtthrough answer!
> Does that make sense?
Absolutely, yes.
The approach brings me a bit farther away from being able to implement it
myself, but not too far I guess ;).
Cheers,
Nik
On Fr, 25.11.22 15:19, Dominik George (n...@naturalnet.de) wrote:
> Hi,
>
> I would like to extend the methods of the User/Group Lookup API[1]
> with an optional argument "onBehalfOf" that carries the authenticated
> user who made the initial method call.
>
> The argument must only be set by a pri
Hi,
I would like to extend the methods of the User/Group Lookup API[1]
with an optional argument "onBehalfOf" that carries the authenticated
user who made the initial method call.
The argument must only be set by a privileged client.
When a client makes a lookup request to the multiplexer, the
m
13 matches
Mail list logo
