Wrong link to /usr/local/share/pam-configs/fscrypt

[Redsandro]

I (manually) installed fscrypt 0.2.9 on Ubuntu 20.04 on a couple of machines, and noticed that while sudo pam-auth-update expects /usr/share/pam-configs/fscrypt but it is actually installed in /usr/local/share/pam-configs/fscrypt (note the local).

On one computer I just copied the file over, and on the other computer I make a symlink:

ln -s /usr/{local,}/share/pam-configs/fscrypt

Both work fine, but I'm not sure what is technically the best workaround.

Perhaps this can be fixed in the Makefile, but that might break things for other distros.

See the following sections in README.md:

fscrypt/README.md

Lines 138 to 141 in 0972347

	Running `sudo make install` installs `fscrypt` to `/usr/local/bin`,
	`pam_fscrypt.so` to `/usr/local/lib/security`, and `pam_fscrypt/config` to
	`/usr/local/share/pam-configs`. Use `make install-bin` to only install
	`fscrypt`. Use `make install-pam` to only install the pam files.

fscrypt/README.md

Lines 335 to 340 in 0972347

	Both the official `fscrypt` package for Ubuntu and `sudo make install`
	will install a configuration file for [Ubuntu's PAM configuration
	framework](https://wiki.ubuntu.com/PAMConfigFrameworkSpec) to
	`/usr/share/pam-configs/fscrypt`. This file contains reasonable
	defaults for the PAM module. To automatically apply these defaults,
	run `sudo pam-auth-update` and follow the on-screen instructions.

Feel free to close this issue if #wontfix because of reasons.

[ebiggers]

The usual convention is for build systems to install to /usr/local/ by default. /usr/ itself is for OS-provided packages.

So if Ubuntu's pam-auth-config only supports /usr/, I'm not sure what to do here.

Of course, there's the option of using sudo make install PREFIX=/usr to install to /usr/ instead. Maybe we should recommend that on Ubuntu, despite it violating the usual convention.

[Redsandro]

Of course, there's the option of using sudo make install PREFIX=/usr to install to /usr/ instead. Maybe we should recommend that on Ubuntu, despite it violating the usual convention.

If anyone else can confirm that the issue described is indeed occurring on their installation of Ubuntu too, then I agree recommending this explicitly is a good idea. If no one experiences this, perhaps it's Linux Mint specific or something else in the way or order of things I use to setup these machines.

[Redsandro]

@ebiggers commented:

despite this not being conventional

So far I've encountered the same in multiple Debian derivatives. I find it hard to find out what the convention is because documentation on this component is slim. I'm getting the impression that in Debian derivatives (such as Ubuntu, Linux Mint, Pop!OS) system components and security contexts should always be in /usr/share, where /usr/local is for local/manual configs, and not supported by their implementation of PAMConfigFrameworkSpec:

• https://wiki.ubuntu.com/PAMConfigFrameworkSpec
• https://wiki.debian.org/LDAP/PAM

Package config declarations are shipped in the packages in /usr/share/pam-configs, and are not user-editable.
no intention to support multiple paths for these configurations; if users want to make changes that are not tied to a package, they should do so directly in the PAM configs. This means in turn that the framework should, to the maximum extent possible, DTRT when the /etc/pam.d/common-* files are edited by users and leave references to unknown modules untouched.

On my (Debian/Ubuntu based) systems, /usr/local only contains a bunch of empty directories, except for some Google Chrome icons and Google Fscrypt configs.

Are we sure Google isn't going against the grain here?

EDIT - Actually your README.md notes are good. I understand the problem - going back to a package. Debian doesn't seem to take manual compilations into account here.

[ebiggers]

Almost all Linux distros use the convention is that /usr is for distro packages, while /usr/local is for manually-installed software.

When you install software from source, it usually goes to /usr/local by default. E.g. this is the case for any software that uses GNU autotools, which is very common; you need to use ./configure --prefix=/usr if you want /usr instead of /usr/local.

The problem here is that Ubuntu's PAM configuration framework (which maybe has been adopted by Debian too?) doesn't take /usr/local into account, and only supports /usr.

[Redsandro]

Thanks for explaining. The prefix works. Can I keep the systems where I manually copied the config file, or will that cause trouble at some point, e.g. when some pam related packages are updated?

[ebiggers]

Manually copying the PAM config file into /usr/share/pam-configs should work fine too.