PAM feature request: include "--enable-vendordir=/usr/local/etc" in build options
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
PAM feature request: include "--enable-vendordir=/usr/local/etc" in build options
It would be great if we could get the official pam package rebuilt with "--enable-vendordir=/usr/local/etc", so that those of us who already did a minimal PAM setup/installation on their own a while ago (in order to be able to keep up with more recent GNOME & freedesktop.org packages, like elogind, lightdm & gnome-flashback, for example) can keep their non-distro-provided stuff in /usr/local, without having to clutter the now distro-provided /etc/pam.d infrastructure.
The plan is to replace Linux-PAM and elogind from my GNU stow setup with Slackware's official packages, and it would be great if the rest my locally installed packages would just keep working. It wouldn't be a problem to keep a local patch for the pam.SlackBuild script and rebuild the official package with that one option added, of course, but it'd be nice if I don't had to.
I wouldn't be opposed to having a vendor dir specified for pam, but it shouldn't point into /usr/local. 'vendordir', as its name suggests, is for Pat(our vendor) to use; /etc/pam.d is for the administrator.
So, Pat would put his stock stuff in /usr/lib/pam.d/ or some such, and you as the local admin get to play with /etc/pam.d
edit: actually, according to this page. There's 3 locations
/etc/pam.d
/usr/lib/pam.d/
<vendor-dir>/pam.d
So Pat could put his stuff in /usr/lib without enabling vendor-dir. What you describe sounds more like a site-dir though, so perhaps the option is misnamed?
Yes, this also exactly matches the source code, and what gets installed with a plain vanilla "make install". From Linux-PAM-1.5.2/libpam/pam_private.h:
Upon installation, all the actual default config files go to /etc/pam.d, and /usr/lib/pam.d remains empty (it actually doesn't even get created, IIRC). The /etc/pam.conf is deprecated (since 1997, as it seems, no less ), and under Linux-PAM-1.5.2/conf/pam_conv1/ you get a small utility to convert an existing /etc/pam.conf to the modern current modular /etc/pam.d structure. The /Linux-PAM-1.5.2/conf/pam_conv1/README says:
Code:
This directory contains a utility to convert pam.conf files to a pam.d/
tree. The conversion program takes pam.conf from the standard input and
creates the pam.d/ directory in the current directory.
The program will fail if ./pam.d/ already exists.
Andrew Morgan, February 1997
So, yeah, the --with-vendordir might be a misnomer. The _DIST_/_DIST2_ parts probably mean "distro dir 1/2". But still, no matter what it's called in the configure script or in the source code, it can be used in whatever way Pat sees fit. And given the rare number of occasions that he actually does see a need to deviate from the plain vanilla upstream sources, having /usr/lib/pam.d at his disposal is probably all he needs in that case, I'd guess (and you seem to agree in the first part of the last line you wrote).
So we still could have this "vendor dir" as the local admin's playground, and putting it into /usr/local/etc would make the most sense from an FHS point of view. Again, I could also live with keeping a local patch for the build script and do a quick rebuild whenever pam gets updated, but of course it would be a lot more convenient if I just could install the official package as-is.
So we still could have this "vendor dir" as the local admin's playground, and putting it into /usr/local/etc would make the most sense from an FHS point of view. Again, I could also live with keeping a local patch for the build script and do a quick rebuild whenever pam gets updated, but of course it would be a lot more convenient if I just could install the official package as-is.
Yes, the "vendordir" name on the 3rd location confused me initially.
To be clear, I'd like to see Pat move the stock pam configs into /usr/lib/pam.d/ leaving /etc/pam.d empty for the admin to use.
I've no objection to your /usr/local/etc pam.d as a third location, but given that /etc/pam.d would be empty and free for the admin to use I do question the usefulness of a 3rd dir under /usr/local/etc.
I've no objection to your /usr/local/etc pam.d as a third location, but given that /etc/pam.d would be empty and free for the admin to use I do question the usefulness of a 3rd dir under /usr/local/etc.
Well, that's just a personal preference. I have tons of stuff installed locally in /usr/local, including stuff that's actually provided by Slackware, but in (much) older versions. This includes the whole freedesktop.org stack, all of GTK/GNOME2/GNOME3, countless Perl, Python2 & Python3 modules, etc. I'm basically using Slackware as a vehicle to boot up my core system and start X, and almost all of my actual desktop is self-compiled and living in /usr/local/stow. I'm making extensive (or should I say excessive? ) use of Slackware's inherent beauty of not getting in your way when you wish to swap out arbitrary parts of the OS, even if it's core parts, and replace them with your own.
Code:
[root@disclosure:~]# ls -1 /var/log/packages/ | wc -l
646
[root@disclosure:~]# ls -1 /usr/local/stow/ | wc -l
4286
[root@disclosure:~]# ls -1 /usr/local/stow/*@{FDO,GNOME,CRYPTO,PYTHON,PERL,MONO,VIRT}* | sort -u | wc -l
1797
So, out of habit, I leave the "official" stuff in /etc and /usr mostly untouched, except for what I need to change to have it include my own stuff in /usr/local. In 95+% of all cases, if you compile something with --prefix=/usr/local, its configuration will end up in /usr/local/etc as well. So having it pre-included as a search path for PAM without the need for a local patch would be very convenient.
Well, that's just a personal preference. I have tons of stuff installed locally in /usr/local, including stuff that's actually provided by Slackware, but in (much) older versions.
Having custom configs stored in /etc/ instead of /usr/local/etc/ would match many other pieces of software, including xorg, modprobe, and udev. Their primary configs are under /usr/ and admins can adjust those by adding files into /etc/.
Personally, I believe /usr/local/etc/ should typically be used for software that is stored in /usr/local/, but Slackware is not my distro to make those types of upper management decisions.
Personally, I believe /usr/local/etc/ should typically be used for software that is stored in /usr/local/, [...]
Yes, and that's exactly what I'm doing (ie. storing/installing software in /usr/local), which in turn is exactly why having PAM include /usr/local/etc/pam.d out of the box would be very convenient.
Having custom configs stored in /etc/ instead of /usr/local/etc/ would match many other pieces of software, including xorg, modprobe, and udev. Their primary configs are under /usr/ and admins can adjust those by adding files into /etc/.
Personally, I believe /usr/local/etc/ should typically be used for software that is stored in /usr/local/, but Slackware is not my distro to make those types of upper management decisions.
The /usr/local/etc would be the lowest precedence of the 3 locations, so it's only useful for adding new rules, not replacing old one. So,
Pat puts the "stock" stuff in /usr/lib/pam.d/
The admin can override that by using /etc/pam.d
and extra stuff can append their own rules by using /usr/local/etc/pam.d.
The /usr/local/etc would be the lowest precedence of the 3 locations, so it's only useful for adding new rules, not replacing old one. So,
Pat puts the "stock" stuff in /usr/lib/pam.d/
The admin can override that by using /etc/pam.d
and extra stuff can append their own rules by using /usr/local/etc/pam.d.
It seems like a sound scheme to me.
I don't have much to add other than I would support that change. I've made a few modifications to the login, sddm, and system-auth pam configs that suit my use better than stock configs. It gets a little tricky with package upgrades making sure that I don't override/revert to stock versions. I wouldn't use the "vendordir" location but just having an option to bypass default configs with customizations that dont get clobbered would be nice.
Yes, and that's exactly what I'm doing (ie. storing/installing software in /usr/local), which in turn is exactly why having PAM include /usr/local/etc/pam.d out of the box would be very convenient.
I thought you meant to not support /etc/, so if /usr/local/etc/ support is in addition to /etc/, I'm all for that.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
It wouldn't be a problem to keep a local patch for the pam.SlackBuild script and rebuild the official package with that one option added, of course, but it'd be nice if I don't had to. 
), and under Linux-PAM-1.5.2/conf/pam_conv1/ you get a small utility to convert an existing /etc/pam.conf to the modern current modular /etc/pam.d structure. The /Linux-PAM-1.5.2/conf/pam_conv1/README says:
