Hi Thorsten,
> > I am confident you did not read my proposal.
>
> I did read it, but you started right from the beginning with a
> technical solution without explaining the problem you want to solve.
> Reverse engineering the problem from a proposal is pretty hard and
> leads most of the time to
Hi Thorsten,
> But this is also the advantage: since it is so old, everything out
> there in the world is supporting it. If you come with a systemd only
> solution: there are also systems without systemd, and ISVs will not
> support two solutions. So whatever you plan, make sure it can be
> called
Hi Erin,
thanks for the feedback!
> Whatever such a protocol ends up looking like, I think “you could replace
> pam_systemd_home with a generic UserDB PAM module and said generic protocol”
> is an important criterion
Yep.
Please note that I am specifically targeting the PAM auth call (and
pro
Hi,
currently, the userdb system only allows querying for User Records and
Group Records, hence providing a modern replacement for NSS.
I would like to propose an addition to make it support authentication as
well. The additions to the io.systemd.UserDatabase Varlink interface
are:
```varlink
#
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
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
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.
>
> 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
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
Hi,
> The former. But you can register users with homed easily. i.e. just
> "upload" a JSON user record to it, and it will manage it. But this
> step is necessary.
That gives me a gratis cache layer on top, right ;)?
But it means that my users will look like homed-managed and cannot be
differen
Hi Lennart,
> (BTW; I kinda hope that one day systemd-homed could directly
> authenticate home directories via OIDC too. In fact, I want it so that
> you can just type in any OpenID identity on a login prompt, and this
> would authenticate a user and create a local homedir on the fly if
> needed.)
Hi,
> how do you intend to support getty logins, i.e. non-graphical
> text-based only logins, where you cannot just open a webbrowser? oidc
> device flow?
Exactly.
> That's tough. PAM has a lot on implicit and explicit state attached to
> the PAM handle... And you can have PAM conversations and
Hi,
> (BTW; I kinda hope that one day systemd-homed could directly
> authenticate home directories via OIDC too. In fact, I want it so that
> you can just type in any OpenID identity on a login prompt, and this
> would authenticate a user and create a local homedir on the fly if
> needed.)
that's
Hi Lennart,
thanks for your elaborate reply (although I completely missed the big
paragraph on the reasons for Varlink in the docs, making that part a
stupid question on my side ;)).
> Basically, a user record consist of multiple sections (i.e. json
> fields contain subobjects), one is called "pr
Hi,
> IMHO your best solution would be to use https://sssd.io/ and
> https://www.keycloak.org/ to bundle your systems together.
>
> Keycloak would speak to your OIDC provider and translates the information in
> something sssd can understand. sssd than is put into your nsswitch.conf as
> provid
Hi,
for some time now, I have been investigating how to best make a
desktop system talk to a web API (HTTP, REST) for user management, so
NSS and PAM make HTTP requests to an API to verify authentication
(using OIDC) and to retrieve NIS information (using REST endpoints).
One of the approaches I
20 matches
Mail list logo
