Commits on Dec 21, 2018

1. security.pam: make pam_unix.so required, not sufficient …

   Having pam_unix set to "sufficient" means early-succeeding account
   management group, as soon as pam_unix.so is succeeding.
   
   This is not sufficient. For example, nixos modules might install nss
   modules for user lookup, so pam_unix.so succeeds, and we end the stack
   successfully, even though other pam account modules might want to do
   more extensive checks.
   
   Other distros seem to set pam_unix.so to 'required', so if there are
   other pam modules in that management group, they get a chance to do some
   validation too.
   
   For SSSD, @PsyanticY already added a workaround knob in
   NixOS#31969, while stating this should
   be the default anyway.
   
   I did some thinking in what could break - after this commit, we require
   pam_unix to succeed, means we require `getent passwd $username` to
   return something.
   This is the case for all local users due to the passwd nss module, and
   also the case for all modules installing their nss module to
   nsswitch.conf - true for ldap (if not explicitly disabled) and sssd.
   
   I'm not so sure about krb5, cc @eqyiel for opinions. Is there some nss
   module loaded? Should the pam account module be placed before pam_unix?
   
   We don't drop the `security.pam.services.<name?>.sssdStrictAccess`
   option, as it's also used some lines below to tweak error behaviour
   inside the pam sssd module itself (by changing it's 'control' field).
   
   This is also required to get admin login for Google OS Login working
   (NixOS#51566), as their pam_oslogin_admin accounts module takes care of sudo
   configuration.

   

   flokli committed Dec 21, 2018
   Configuration menu

   • View commit details
   • Copy full SHA for d180bf3
   • Browse repository at this point

   Copy the full SHA

   d180bf3 View commit details

   Browse the repository at this point in the history