6 ms·

> Why on earth put pam_ on the front of the modules and .so on the end Because it uses dynamic linking of the shared libraries used for authentication.

cormacrelf 5y ago
A further serious answer for those unfamiliar, the .so files are all found in a PAM module search path. You can replace a search-path-relative path (pam_blah.so) with an absolute path to a .so file if you wish. auth required /etc/whatever/my_pam_module.so
gerdesj 5y ago
I was being facetious. The config file doesn't need to worry about the nuts and bolts. All of the PAM modules are named pam_xxxxx.so so the configuration file only needs to specify the name, ie the xxxxx. Also some parts of the configuration are abbreviated, eg: auth and other bits are not, eg: password. Those "[success = n" things mean "skip this number of lines if this invocation succeeds. It's a pretty mad "if f(x) == true goto n" statement. Begrudgingly I have to say that despite the oddness of it all, it is reasonably easy to follow what is going on when you understand the rules.
- notyourday 5y ago
  It is because when we wrote the parser for it our goal was to make it braindead simple.
  - ncmncm 5y ago
    Who is "we", here?
    - gerdesj 5y ago
      "We" I suspect you have awoken the Dark Ones (errr the PAM devs)
      - xena 5y ago
        Honestly if this is how you get in contact with the PAM devs I should have done this a lot sooner.
        gerdesj 5y ago
        The Dark Lords are always here. PAM is pretty odd but not that bad!
- adrianmonk 5y ago
  > All of the PAM modules are named pam_xxxxx.so so the configuration file only needs to specify the name, ie the xxxxx. I would rather type a few extra characters so that it is blindingly obvious that "pam_foo.so" in the config file will load code from pam_foo.so in the filesystem. Typing only "foo" would remove a little clutter, but it would also increase my cognitive load a little.
  - tablespoon 5y ago
    >> All of the PAM modules are named pam_xxxxx.so so the configuration file only needs to specify the name, ie the xxxxx. > I would rather type a few extra characters so that it is blindingly obvious that "pam_foo.so" in the config file will load code from pam_foo.so in the filesystem. > Typing only "foo" would remove a little clutter, but it would also increase my cognitive load a little. Exactly. Sometimes magic like what the GP wants is evil. It sub-optimally trades a steeper learning curve for some too-small convenience. It's like buying a shiny new penny for a dollar.
    - notyourday 5y ago
      > It's like buying a shiny new penny for a dollar. That's bonk. PAM significantly simplified the ecosystem - at the time there were dozens specialized hack upon hack upon hack login suits such as * login-otp * login-shadow * login-skey * des-login * login-rsa-otp that implemented some of the functionality for some of the manipulations, sometimes on the same system. Some of them already used shared libraries and some of those shared libraries already used the names. Specifying loading paths fully was considered a bad idea because of how subsystems were installed on the deployed servers. The decisions about name collisions ( pam_ prefix ), following Sun's original specs ( some of the names of stages ), etc were made from those constraints. It needed to be deployable on the top of the existing login systems where the users would not be locked out because of some sort of a conflict. PAM significantly simplified that messy ecosystem while being extremely system, which is why it won and remains the integral part of the ecosystem for twenty seven years. But hey, this is open source -- don't like it? Rewrite it in Rust! Just remember that first you would need to make sure that Rust exists on all the platforms PAM has been used on.[0] [0] Pam-static was created as during the first few releases Linux/Alpha did not have support for shared libraries. So there it was, Pluggable Authentication Modules which on Alpha did not have dynamic loaders.
- rwmj 5y ago
  udev also suffers from a similar config not-quite-programming-language syntax. My theory is that the authors of both didn't know about parser generators.
  - notyourday 5y ago
    Considering that some of the people behind PAM had their hands in the writing/patching those parsers, I doubt it
deleted 5y ago
[deleted]

cormacrelf 5y ago

A further serious answer for those unfamiliar, the .so files are all found in a PAM module search path. You can replace a search-path-relative path (pam_blah.so) with an absolute path to a .so file if you wish. auth required /etc/whatever/my_pam_module.so

gerdesj 5y ago

I was being facetious. The config file doesn't need to worry about the nuts and bolts. All of the PAM modules are named pam_xxxxx.so so the configuration file only needs to specify the name, ie the xxxxx. Also some parts of the configuration are abbreviated, eg: auth and other bits are not, eg: password. Those "[success = n" things mean "skip this number of lines if this invocation succeeds. It's a pretty mad "if f(x) == true goto n" statement. Begrudgingly I have to say that despite the oddness of it all, it is reasonably easy to follow what is going on when you understand the rules.

notyourday 5y ago
It is because when we wrote the parser for it our goal was to make it braindead simple.
- ncmncm 5y ago
  Who is "we", here?
  - gerdesj 5y ago
    "We" I suspect you have awoken the Dark Ones (errr the PAM devs)
    - xena 5y ago
      Honestly if this is how you get in contact with the PAM devs I should have done this a lot sooner.
      - gerdesj 5y ago
        The Dark Lords are always here. PAM is pretty odd but not that bad!
adrianmonk 5y ago
> All of the PAM modules are named pam_xxxxx.so so the configuration file only needs to specify the name, ie the xxxxx. I would rather type a few extra characters so that it is blindingly obvious that "pam_foo.so" in the config file will load code from pam_foo.so in the filesystem. Typing only "foo" would remove a little clutter, but it would also increase my cognitive load a little.
- tablespoon 5y ago
  >> All of the PAM modules are named pam_xxxxx.so so the configuration file only needs to specify the name, ie the xxxxx. > I would rather type a few extra characters so that it is blindingly obvious that "pam_foo.so" in the config file will load code from pam_foo.so in the filesystem. > Typing only "foo" would remove a little clutter, but it would also increase my cognitive load a little. Exactly. Sometimes magic like what the GP wants is evil. It sub-optimally trades a steeper learning curve for some too-small convenience. It's like buying a shiny new penny for a dollar.
  - notyourday 5y ago
    > It's like buying a shiny new penny for a dollar. That's bonk. PAM significantly simplified the ecosystem - at the time there were dozens specialized hack upon hack upon hack login suits such as * login-otp * login-shadow * login-skey * des-login * login-rsa-otp that implemented some of the functionality for some of the manipulations, sometimes on the same system. Some of them already used shared libraries and some of those shared libraries already used the names. Specifying loading paths fully was considered a bad idea because of how subsystems were installed on the deployed servers. The decisions about name collisions ( pam_ prefix ), following Sun's original specs ( some of the names of stages ), etc were made from those constraints. It needed to be deployable on the top of the existing login systems where the users would not be locked out because of some sort of a conflict. PAM significantly simplified that messy ecosystem while being extremely system, which is why it won and remains the integral part of the ecosystem for twenty seven years. But hey, this is open source -- don't like it? Rewrite it in Rust! Just remember that first you would need to make sure that Rust exists on all the platforms PAM has been used on.[0] [0] Pam-static was created as during the first few releases Linux/Alpha did not have support for shared libraries. So there it was, Pluggable Authentication Modules which on Alpha did not have dynamic loaders.
rwmj 5y ago
udev also suffers from a similar config not-quite-programming-language syntax. My theory is that the authors of both didn't know about parser generators.
- notyourday 5y ago
  Considering that some of the people behind PAM had their hands in the writing/patching those parsers, I doubt it

deleted 5y ago

[deleted]