FS#61790 - [pambase] Default configuration files should be placed in /usr/lib/pam.d and NOT /etc/pam.d

Attached to Project: Arch Linux
Opened by AMM (amish) - Sunday, 17 February 2019, 05:40 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:13 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To David Runge (dvzrv)
Levente Polyak (anthraxx)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No

Details

Description:
From PAM manpage (man pam):

FILES
/etc/pam.d: the Linux-PAM configuration directory. Generally, if this directory is present, the /etc/pam.conf file is ignored.
/usr/lib/pam.d: the Linux-PAM vendor configuration directory. Files in /etc/pam.d override files with the same name in this directory.

So the PAM configuration files that are shipped by Arch repositories should be placed in /usr/lib/pam.d and then administrator can modify settings by placing file with same name in /etc/pam.d

This is also behavior for many known packages (for e.g systemd) where vendor specific files are placed in /usr and administrator can customize it in /etc without modifying the default configuration.

This will also simplify package upgrades without leaving behind .pac{new,save} files

Additional info:
* package version(s)
All packages obtained via "pacman -Qo /etc/pam.d"

* config and/or log files etc.
As above

Please consider the change. Thanks.
This task depends upon

Closed by  Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:13 GMT
Reason for closing:  Moved
Additional comments about closing:  https://gitlab.archlinux.org/archlinux/p ackaging/packages/pambase/issues/1
Comment by Dave Reisner (falconindy) - Sunday, 17 February 2019, 22:14 GMT
My 2 cents:

Since you mention systemd, but nothing else, let's consider how systemd handles this. While you can wholesale replace a unit in /usr/lib/systemd with a unit of your own design in /etc/systemd, systemd offers an extension mechanism with drop-ins. This is particularly interesting because it allows you to integrate upstream changes to the base unit file while keeping your overrides, providing only the minimal required site-local configuration.

> This will also simplify package upgrades without leaving behind .pac{new,save} files

It simplifies upgrades, but introduces added complexity for anyone maintaining a site-local override -- the current notion of introducing the pacnew is a *really* strong signal that you should review the new files and integrate any changes in your own config. You'll entirely lose this with your proposal. I suppose we could introduce a post-transaction hook to call out when pam config changes in /usr/lib/pam.d with a matching override in /etc/pam.d, but I'm not convinced that's any better than what we currently have. There's potentially a case to be made for moving to /usr/lib/pam.d if you're a fan of the "empty /etc" mantra.

If anyone wants to tackle this, the rebuild list is large, and we should probably write a news item:

core/cronie
core/inetutils
core/openssh
core/pambase
core/shadow
core/sudo
core/systemd
core/util-linux
extra/bftpd
extra/cups
extra/gdm
extra/lightdm
extra/plasma-workspace
extra/polkit
extra/postgresql
extra/samba
extra/screen
extra/sddm
extra/slim
extra/xorg-xdm
extra/xscreensaver
community-staging/xpra
community/cinnamon-screensaver
community/deepin-daemon
community/fcron
community/gnome-screensaver
community/i3lock
community/lxdm
community/lxdm-gtk3
community/mate-screensaver
community/open-vm-tools
community/partimage
community/physlock
community/schroot
community/squid
community/sssd
community/sway
community/xpra
Comment by Eli Schwartz (eschwartz) - Monday, 18 February 2019, 01:05 GMT
Typically the most significant reasons to use /etc and /usr/lib is the extending case, which requires support that Pam doesn't have? and the case of masking something to /dev/null which is probably not what you want for pam either.

One additional use case where this actually works out well is for someone that maintains their /etc configuration via pacman packages, as it's quite impossible to have two packages own the file.

I don't know that that is actually worth the cost of people not knowing when to merge changes in a format that doesn't allow for foo.conf.d extensions.
Comment by AMM (amish) - Monday, 18 February 2019, 02:23 GMT
Well udev does similar to what pam does. Vendor files go in /usr and customization in /etc

And talking of systemd, its sub-programs tmpfilesd, sysuser.d also do similar.

There may be more such softwares.

The point is that most popular softwares have now started to consider /etc as reserved for local administrator customization and /usr as their default place for default config.

Also if an administrator has customizaed PAM config then administrator is supposed to know what he is doing because PAM is very center of authentication for most softwares.

So if he has modified default files - he knows that he DOES NOT want a default config anyway. And he most likely is expected to keep and review it on his own.

And if he still wants to use MIX of his config and default config he can always use "include" at appropriate place in his customization.

For e.g:

> cat /etc/pam.d/system-remote-login
auth required pam_google_authenticator.so forward_pass
auth include /usr/lib/pam.d/system-remote-login
account include /usr/lib/pam.d/system-remote-login
password include /usr/lib/pam.d/system-remote-login
session include /usr/lib/pam.d/system-remote-login

Above uses Default config + adds support for Google Authenticator. (it also serves as case of extending the default config)

That is this will allow them to use their customization as well as continue to use default config too.

And if it still breaks things - well Arch is known to break things now and then for users having own customization. And they are supposed to FIX it on their own.

Hope I do make sense and we do start following what is becoming standard practice which separates vendor/distribution config and Local config
Comment by AMM (amish) - Monday, 18 February 2019, 02:39 GMT
@falconindy
> If anyone wants to tackle this, the rebuild list is large, and we should probably write a news item:

Its not necessary to rebuild all at once. We can start with [core]. And overtime everything can be migrated.

Its not going to break things if some package use /usr/lib/pam.d and other still use /etc/pam.d. (unless somewhere someone "WRONGLY" used absolute path /etc/pam.d/SERVICENAME instead of just giving SERVICENAME but then its their mistake and should be corrected)

If administrator has customized a file in /etc/pam.d then I believe switch to /usr/lib/pam.d will leave behind .pacsave which they are supposed to rename without .pacsave.

OR a post install script can do that and NOTHING would break.

Like this (example picked from grub package).

if [ ! -f /etc/pam.d/SERVICE -a -f /etc/pam.d/SERVICE.pacsave ]; then
mv /etc/pam.d/SERVICE.pacsave /etc/pam.d/SERVICE
fi

This would make sure that nothing breaks even if default file is now moved to /usr/lib/pam.d

Or a pacman hook which monitors changes to /etc/pam.d and calls:
rename --no-overwrite .pacsave "" /etc/pam.d/*.pacsave
Comment by Dave Reisner (falconindy) - Monday, 18 February 2019, 03:18 GMT
Just because we *could* do this piecemeal doesn't mean we should. That just adds to the confusion

systemd provides tooling to make tracking differences between /usr and /etc easy -- see systemd-delta.
Comment by AMM (amish) - Monday, 18 February 2019, 03:44 GMT
We dont need additional tool to look for difference in pam config. diff is enough.

And systemd needs such software because its very complex and HUGE amount of config directives. PAM is not as complex as systemd. It has only 4 types of config lines. Not so complex.

Anyway I have given the solution.

You are making it look complicated and it is not.

1) There is no need to migrate all packages at once.
2) Moving file from /etc/pam.d to /usr/lib/pam.d is not going to break anything except if there is customization
3) Even if there is customization ... pacman will throw a warning about .pacsave file --- sufficient enough to warn user that action needs to be taken.

Main principle of Arch is to follow upstream and its advice (example is recent change to pambase "other" file). See: https://bugs.archlinux.org/task/48650

If upstream says put your distribution files in /usr/lib/pam.d then Arch by its principle should put it there.

That is all I have to say to put across my point.
Comment by Jake Kreiger (Magali75) - Monday, 18 February 2019, 11:11 GMT
Users could still modify files directly in /usr/lib/pam.d if this is what they prefer (and receive pacnew files).
Comment by AMM (amish) - Monday, 18 February 2019, 11:34 GMT
In most likely case files moved to /usr/lib/pam.d should not be in backup=() array of PKGBUILD.

So any modification would be lost on upgrade (without pacnew file). (unless package builders decide to keep it in backup array - however it should not be done so)

Any cutomization should be encouraged to be done in /etc/pam.d only.
Comment by Dave Reisner (falconindy) - Monday, 18 February 2019, 12:46 GMT
I'm happy to engage in discussion when you can address my concerns about the longer term implications of this move.
Comment by AMM (amish) - Monday, 18 February 2019, 13:51 GMT
Thank you. And same here. I will discuss further only if you prove that this move is going to break things for anyone. And what longer term implications are you talking about? I dont see any long term implication. I have addressed everything in my opinion.

Properly written pam conf file will not break anything even after upgrade. Be it a complete replacement of default or be it an extension to default via include statements (example that I gave earlier)

Regards, peace and cheers!
Comment by Dave Reisner (falconindy) - Monday, 18 February 2019, 15:21 GMT
As an example: Explain to me what happens when someone overrides one of the pambase includes to reorder, exclude/include some module? What happens when we, upstream, introduce a new module such as pam_systemd.so which is effectively required?

Current system: You get a pacnew, you merge it. There's a standard, well known process for managing this.

With proposed changes: the file in /usr/lib/pam.d changes, the user has no such notification that the file has been altered. They'll likely end up digging through logs to figure out what was upgraded and *maybe* make the connection.
Comment by AMM (amish) - Monday, 18 February 2019, 16:43 GMT
If user has reordered / excluded things thats how he wants it. And he does not care what default order is. So even after upgrade, his preferred order will remain as is. Whatever be default he wouldnt care.

Same applies for systemd too. If service file introduces something new or changes something - user will NOT know even if he has drop-in in place. Because there is no pacnew file generated.

Say for example in default service file:
Type changes from simple to fork.

But user drop-in did not have its own Type= line (because he assumed that default service file has Type=simple so no need to mention it again in drop-in) then its going to break things for him (as his Execstart= was assuming type as simple) and he will indeed have to go looking in to logs to find out what went wrong.

(Something similar happened with me with IWD package. See IWD thread in BBS if you want to know. Eventually the latest iwd.service file is doing what my drop-in was doing and I have now done away with drop-in)


Coming back to topic.

For cases where a new module is introduced. A news / announcement item can be created at that time. (but how many times do we introduce new REQUIRED module anyway?)

Plus Arch is DIY system. It has broken things in past and it will continue to break things in future for some or other users. You cant please everyone but you can follow standard recommendations. (which I am insisting here)


Now let me try to explain the advantage of having /usr/lib/pam.d.

If I want my custom modules added. All I do is:

> cat /etc/pam.d/system-remote-login
auth required pam_google_authenticator.so forward_pass
auth include /usr/lib/pam.d/system-remote-login
account required pam_geoip.so
account include /usr/lib/pam.d/system-remote-login
password include /usr/lib/pam.d/system-remote-login
session include /usr/lib/pam.d/system-remote-login

I enjoy added security of two factor authentication plus GeoIP based access.

And continue to have benefits of default config.

Even if in future new REQUIRED module (like pam_systemd.so) is added I will automatically get it.

I dont have to worry about checking and merging and deleting everytime something changes in default file.

If ever I want to go back to default I simply delete my custom file.

I dont have to keep track of which file I modified and which not.. whatever exists in /etc/pam.d is what I have modified.

If I ever want to know what I had changed, I simply run:
diff /usr/lib/pam.d/fooservice /etc/pam.d/fooservice


Now I leave it to you to decide if there are more advantages or disadvantages.

Thank you for reading up until here. :)
Comment by AMM (amish) - Friday, 03 May 2019, 05:45 GMT
While we still come to conclusion on what to do with this bug report, I would like to propose that:
We move PAM files to /usr/lib/pam.d but continue to keep it in backup array.

So if user wants to customize it ...
1) ... but wants to be informed about vendor file change (i.e. have a pacnew file generated), they can modify the file in-place (i.e. one in /usr/lib/pam.d). Hopefully this will satifsy @falconindy
2) ... and wants an override without bothering about any future changes in vendor file, they can place their copy in /etc/pam.d

This will:
1) Continue existing behavior (except change in location)
2) Put the file in proper place as suggested by upstream
3) Allow flexibility to user like me.

PS: as mentioned by me earlier there is no need to migrate all packages at once. Package maintainers can do it at their convenience.

Thank you
Comment by AMM (amish) - Monday, 23 September 2019, 11:10 GMT Comment by Eli Schwartz (eschwartz) - Monday, 23 September 2019, 13:17 GMT
So you're saying that the squid package is nonconformant with the rest of Arch Linux's file hierarchy, resulting in squid users potentially being confused about where to find their pam.d configurations?

I agree, that is a bug -- we should switch it back until and unless the repository-wide policy is changed.
Comment by nl6720 (nl6720) - Monday, 23 September 2019, 14:10 GMT
If there's no official policy, then there's nothing to be nonconformant against.
Comment by AMM (amish) - Monday, 23 September 2019, 14:34 GMT
@eschwartz - If there is no policy then Arch policy would be to follow what upstream says? Isn't it?

It is not a bug. It just follows upstream recommendation about where to place vendor files.

And I am not saying its nonconformant, you are mis-interpreting. I am infact for this change not against this change.
Comment by Andreas Radke (AndyRTR) - Tuesday, 10 December 2019, 18:37 GMT
I guess this should be brought to the dev-public mailing list to be discussed.
Comment by AMM (amish) - Monday, 26 October 2020, 23:55 GMT
Even systemd is now moving PAM configuration to /usr/lib/pam.d.

https://lists.freedesktop.org/archives/systemd-devel/2020-October/045505.html

Given that PAM stack
definitions are primarily put together by OS vendors/distributions
(though possibly overridden by users), this systemd release moves its
own PAM stack configuration for the "systemd-user" PAM service (i.e.
for the PAM session invoked by the per-user user at .service instance)
from /etc/pam.d/ to /usr/lib/pam.d/. We recommend moving all
packages' vendor versions of their PAM stack definitions from
/etc/pam.d/ to /usr/lib/pam.d/, but if such OS-wide migration is not
desired the location to which systemd installs its PAM stack
configuration may be changed via the -Dpamconfdir Meson option.

Isn't it high time we decide on the same?

Thank you.
Comment by Buggy McBugFace (bugbot) - Tuesday, 08 August 2023, 19:11 GMT
This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.
Comment by AMM (amish) - Friday, 15 September 2023, 12:41 GMT
Replying to above comment by @bugbot (Buggy McBugFace) to avoid auto-closing of this "bug".

As issue still remains to be decided and concluded upon.
Comment by David Runge (dvzrv) - Monday, 18 September 2023, 13:47 GMT
Seeing that we have many more packages with their PAM integration below /etc/pam.d/ we'll likely require a TODO for this.
I'll look into that once shadow 4.14.0 has landed successfully.

Loading...