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
https://github.com/NixOS/nixpkgs/pull/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
(#51566), as their pam_oslogin_admin accounts module takes care of sudo
configuration.
pkgs.owncloud still pointed to owncloud 7.0.15 (from May 13 2016)
Last owncloud server update in nixpkgs was in Jun 2016.
At the same time Nextcloud forked away from it, indicating users
switched over to that.
cc @matej (original maintainer)
* run as user 'slurm' per default instead of root
* add user/group slurm to ids.nix
* fix default location for the state dir of slurmctld:
(/var/spool -> /var/spool/slurmctld)
* Update release notes with the above changes
TrueCrypt has been retired for a while now and the source archive we
pointed to is gone. Moreover the VeraCrypt fork is available, maintained
and fixes issues previous audits found in TrueCrypt.
Nixpkgs' channel currently can't move forward so long as there is a
trace in evaluating the top-level arguments. Which means that it isn't
possible to add a warning message to warn users of future package
removal.
So the only way forward appears to be just removing the alias
altogether.
(cherry picked from commit b4133ebc17)
