Will it be possible to change the order of modules? For example: SSSD won't work unless it comes before Unix

Will it be possible to change the order of modules? For example: SSSD won't work unless it comes before Unix

Yep! That's something I forgot to add as an example.

For example:

security.pam.services.login.password.sssd.order = 100;

Might have to mkForce it as things stand, and thus I might have to put some mkDefault in there.

find a better way to create services with no defaults. See "Creating a custom service, using none of the defaults" above. The goal is to get rid of those mkForce. I also require help with this. Maybe have the PAM modules add their entries with mkDefault? Solution is in e356a70

Some explanation regarding this. Due to the way the security.pam.services.<...>.{auth,account,password,session} are merged together, we currently (with the commit mentioned above) end up with something like this:

config.security.pam.services.<...>.account = mkDefault {
  unix = { ... };
  ldap = { ... };
# ... you get the gist of it
};

Each PAM pipeline (auth, account, password, session) is a big mkDefault. This is great for services that do not want to register any default. They just have to say:

config.security.pam.services.serviceWithoutAccountDefault = {
  account = {};
  auth = {
    customEntry = { ... };
  };
};

Which means "hey, I don't want any of those defaults for the account pipeline, here is my custom pipeline for auth, and leave the default for the two other pipelines". Which is great! We want that kind of customization (i.e. service can choose which pipeline they want to override). However, where it falls short is for a user who wants to override the order, for example:

config.security.pam.services.login.account.krb5.order = 1;

This overrides the whole account pipeline and evaluation will fail with The option 'security.pam.services.login.account.krb5.control' is used but not defined.. The resulting login.account actually looks like this:

{
  krb5 = {
    order = 1;
  };
} 

and that's it. No wonder it fails.

Now, the solution I see:

• reverting the mentioned commit above: hard pass, it requires services to mkForce their customization
• don't do anything: hard pass, we don't want the users to have to rewrite the whole pipeline just for changing the order
• make a security.pam.services.<...>.includeDefaults (or exclude, more on that later) that is a boolean that services can use to get rid of the defaults: meh, it doesn't allow for the level of customization we currently have, i.e. the ability for services to choose which pipeline they want to override
• make a security.pam.services.<...>.includeDefaults (or exclude, more on that later) that is a list that defaults to [ "account", "auth", "password", "session" ] ([] if the option is exclude) that explicitly specifies which defaults the services want to keep: and I think I'll go with this one.

Shortcoming of this: requires even more logic then there already is in the modules code, for each pipeline they would have to do something like pipeline = mkIf (any (p: p == "pipeline") config.includeDefaults) { ... }; which is much too heavy. This means that this step is block by the refactoring described above, i.e. make a mkPamModule function to easly create those.

About the include or exclude choice, I don't know which to choose. Services are more likely to drop all pipelines, which would make using includeDefaults easy (just set it to [] to ignore all defaults), but then exclude would be more explicit in which pipelines the service drops. Any take on this?

EDIT: formatting, typos

Refactor the modules in nixos/modules/security/pam/modules with a function that does the submodule part of the work. I require help with this, all I can seem to get are infinite recursion errors...

Here is a patch that gives said error. I have no idea why this is happening. Any help would be welcomed and much appreciated! https://bin.lama-corp.space/raw/1k5M1WoUC6_H8MaqGOggc

EDIT: @infinisil found the problem and I was able to implement a PoC of the refactoring in f9e4acb07b04633804d5589235eb686351fc625d e38a39fdaf2f15276fc7f54610d93662e46275fa

I wonder if all the orders should be mkDefaulted...

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/reworking-the-nixos-pam-module-a-walk-through/10334/1

Haven't done more than glance at these changes yet, but it seems likely it will at least partially, if not fully, address #95017. Locally I've been using my own override that does what appears to be similar to security.pam.modules.krb5.enable in this PR so that's great.

In that issue there's also the error pam_ccreds: failed to open cached credentials "/var/cache/.security.db": No such file or directory. I mention this because I don't know whether that error happens because in my case Kerberos wasn't set up for login auth, therefore it never succeeded and therefore nothing to cache, or whether something with the existing PAM/Kerberos setup in NixOS didn't create the file or doesn't allow PAM to create the file.

Haven't done more than glance at these changes yet, but it seems likely it will at least partially, if not fully, address #95017. Locally I've been using my own override that does what appears to be similar to security.pam.modules.krb5.enable in this PR so that's great.

In that issue there's also the error pam_ccreds: failed to open cached credentials "/var/cache/.security.db": No such file or directory. I mention this because I don't know whether that error happens because in my case Kerberos wasn't set up for login auth, therefore it never succeeded and therefore nothing to cache, or whether something with the existing PAM/Kerberos setup in NixOS didn't create the file or doesn't allow PAM to create the file.

pam_ccreds is a PAM module that saves a hash a a user's password when they logged in kerberos. In the event that a user locked its workstation, and the KDC goes down, the user will still be able to unlock (only unlock, not log in, as in creating a new session) their computer using their password. From your description of the issue, I don't exactly know what's going wrong, but if you're not using kerberos with PAM, with this PR, a simple security.pam.modules.krb5.enable = false; will do the trick.

Also, I'll add a quick comment about PAM activation by default when krb5 is enabled, tell me what you think is best.

I'll try to have a more detailed review of this tomorrow and Monday, it's a big PR! I've read through the descriptions and the proposals look sensible. I'll try and review the implementation in a bit more detail tomorrow and Monday.

Is the idea of pam.module.foo.enableAuth to give a single switch to enable/disable all auth-related rules for that module? There seems to be some naming inconsistency, with a few enableAuth and a few enableAuthentication, or is there a difference between these?

Perhaps renaming security.pam.modules to defaults or defaultModules would be a little clearer? Otherwise, it's a little confusing whether pam.modules.foo.enable = false; disables it globally (i.e. overriding services) or not.

I also want to discuss the use of orderOf - I think having a order key until that is merged is fine (and a good idea to keep the two PRs independent). However, I think there is an advantage to expressing rules as a partial ordering, because it keeps the intention clearer. For example, if I have

modules.a.after = x: x.name == "d" || x.name == "c";
modules.b.after = x: x.name == "d";
modules.c.after = x: x.name == "d";
modules.d.after = x: false;

This makes the dependencies between modules clear. Whereas an ordering to achieve the same dependencies might be:

modules.a.order = 2500;
modules.b.order = 2000;
modules.c.order = 1500;
modules.d.order = 1000;

This defines an order that satisfies the dependencies, but doesn't make clear which parts of the relationship are important.

I'd like to see the conversations on the other PR resolved before merging this:

• Use of attrsets for PAM module arguments
• include/substack - allowing nix-defined entries (rather than just paths)

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nix-office-hours/11945/14

I'm currently stumbling in the dark with PAM, slowly making some sense of some things in #119710 , if we can do anything to improve the debugging experience, that would be cool.

As a small note, pam_unix.so also takes an audit flag which the man page says gives more output than debug but I haven't really confirmed that.

I'm currently waiting for a large rebuild, but the --enable-debug flag may be of interest; adding a flag to the nix package and a flag in the module to toggle it.

Is this pr still active?

Is this pr still active?

This PR is way too huge to be merged as is. However, it exposes the ideas I had for refactoring the PAM module.

We had a discussion with @Pamplemousse a while ago about how to break it down into smaller, more reviewable PRs. Hit us up if you want to discuss it!

Well you still deserve a huge thank you for the huge effort behind the bold PR, thank you!

@rissson, thanks for the massive contribution. Hopefully at some point we can get this reworked and merged in more manageable steps. Since you expressed above not wanting to merge this as is, I hope you don't mind if I go ahead and close it for now.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/what-do-you-want-from-pam-security-pam-in-nixos/33265/2

Did anyone rework pam yet?

@nyabinary Some work was done with #255547!