Heya! Ricardo Wurmus <rek...@elephly.net> skribis:
> My findings so far: > > * NSCD *must* be extended with caches for “passwd” and “group” > databases or else applications will make the lookup for user accounts > directly and will not consult LDAP at all. Nscd already has caches for those in our default configuration, doesn’t it? > * it’s a pity that “name-service-switch” is not a system service and has > to be extended manually. … Or is this perhaps how we should treat PAM > configuration as well? We should turn ‘name-service-switch’ into an extensible service, IMO. It just happens to predate the service type graph. > But back to the problem of authenticating users via LDAP. With our > default unix-pam-service “pam_unix.so” (which checks that a user account > exists locally and checks its password) is required, so LDAP > authentication will always fail. > > I extended the pam-root-service-type with a service that matches on all > pam_unix.so modules and makes them use the “sufficient” keyword instead > to overcome this. So you’re extending ‘pam-root-service-type’ with a “transformation” procedure, right? > This is problematic when nslcd-service-type is involved because it > extends pam-root-service-type to add entries for pam_ldap.so. Instead > of using a string “pam_ldap.so” it uses a G-expression to compute the > absolute file name of “pam_ldap.so”. When extending the service and > matching on PAM entries, however, we don’t have a string of the > absolute file name to match on — we have a G-expression that is really > awkward to match against. Could you match against a <file-append> record? > I worked around this (by lowering the G-expression first), but it’s > ugly. And even then I still have the problem that I can’t control the > order of PAM entries at all. Perhaps we could add a field in <pam-configuration> that would be transformation procedure that takes the complete list of entries? > Perhaps we should implement a different mechanism for specifying PAM > entries for the system, perhaps similar to what the name-service-switch > field does? We could also allow users to specify (service pam-root-service-type (pam-configuration …)) in their ‘services’ field. Would that help? > I also recommend using “sufficient” as the default keyword for > “pam_unix.so” and ending the stack with “required pam_deny.so”. This > would make it easier to extend the stack without having to rewrite > existing module entries. Why not. Tricky issues! NixOS has lots of hard-coded cases instead of a generic way to extend PAM settings: https://github.com/NixOS/nixpkgs/blob/release-19.03/nixos/modules/security/pam.nix#L304 >From what you wrote, it may be that PAM configuration is simply not “composable”, in the sense that you cannot assemble bits without viewing the global picture. Thanks, Ludo’.
