fprintd: fix the shared object install path for pam_fprintd

[aokblast]

Summary

The openpam in FreeBSD search the .so in /usr/local/lib instead of
/usr/local/lib/security. In this patch, we move the binary to the correct
location.

[lwhsu]

I found that currently all the pam_* ports install pam_*.so under lib/security/, perhaps we also need to check if the behavior of openpam has been changed.

[aokblast]

There is no change. See pam.conf(5).

The module-path field specifies the name or full path of the module to
     call.  If only the name is specified, the PAM library will search for it
     in the following locations:

     1.   /usr/lib

     2.   /usr/local/lib

Then use git blame

git blame contrib/openpam/doc/man/pam.conf.5

It shows these line is added from import of 2013 pam module

[lwhsu]

In D50239#1146150, @aokblast wrote:

There is no change. See pam.conf(5).

The module-path field specifies the name or full path of the module to
     call.  If only the name is specified, the PAM library will search for it
     in the following locations:

     1.   /usr/lib

     2.   /usr/local/lib

Then use git blame

git blame contrib/openpam/doc/man/pam.conf.5

It shows these line is added from import of 2013 pam module

Understood, but I am wondering why the original version worked, and all other ports install pam_*.so into lib/security/. I suspect that the pam library in the base system also searches modules under lib/security/ but undocumented, and that behavior has been modified or removed.

If that's the older behavior of pam, I'm not sure if we should restore it, or update all the ports install pam module into lib/security/ ...

[aokblast]

No, see git blame contrib/openpam/lib/libpam/openpam_constants.c of history of openpam_module_path

We never overwrite it

In D50239#1146151, @lwhsu wrote:

In D50239#1146150, @aokblast wrote:

There is no change. See pam.conf(5).

The module-path field specifies the name or full path of the module to
     call.  If only the name is specified, the PAM library will search for it
     in the following locations:

     1.   /usr/lib

     2.   /usr/local/lib

Then use git blame

git blame contrib/openpam/doc/man/pam.conf.5

It shows these line is added from import of 2013 pam module

Understood, but I am wondering why the original version worked, and all other ports install pam_*.so into lib/security/. I suspect that the pam library in the base system also searches modules under lib/security/ but undocumented, and that behavior has been modified or removed.

If that's the older behavior of pam, I'm not sure if we should restore it, or update all the ports install pam module into lib/security/ ...

[lwhsu]

@des: what's the correct path for pam modules installed from ports? ${PREFIX}/lib or ${PREFIX}/lib/security ?

[des]

In D50239#1148142, @lwhsu wrote:

@des: what's the correct path for pam modules installed from ports? ${PREFIX}/lib or ${PREFIX}/lib/security ?

The former, otherwise you have to use the full path in the policy file. OpenPAM does not look for a security subdirectory and never has. As far as I can tell, FreeBSD didn't use a security subdirectory even when we had Linux-PAM. I'm not sure who made that decision (jdp I guess?) or why, but since I wrote OpenPAM mainly for the purpose of replacing Linux-PAM in FreeBSD, I followed FreeBSD's example rather than use Linux-PAM's upstream default.

[aokblast]

Use symlink instead of copy file

[des]

security/fprintd/Makefile

27

ln is usually spelled ${LN} in Makefiles.

[aokblast]

Use LN instead of ln

[aokblast]

For sombody who want to merge this patch, thanks!
https://github.com/aokblast/freebsd-ports/commit/1f4c377b046f9153cd1942ea11c7473f87437f03

[danfe]

@des wrote:

OpenPAM does not look for a security subdirectory and never has.

@lwhsu wrote:

Understood, but I am wondering why the original version worked, and all other ports install pam_*.so into lib/security/.

Before we proceed, do we have a definitive answer for these two questions? If there's a bigger problem here I'd rather fix that instead of band-aiding individual port(s).

[des]

In D50239#1152212, @danfe wrote:

@des wrote:

OpenPAM does not look for a security subdirectory and never has.

@lwhsu wrote:

Understood, but I am wondering why the original version worked, and all other ports install pam_*.so into lib/security/.

Before we proceed, do we have a definitive answer for these two questions?

The first is not a question, it's a statement.

The answer to the second is that even though the module is in the wrong location, it still works if you provide the full path in your PAM policy.

We can either:

1. fix all ports that install PAM modules to install them in the correct location, but that will break existing configurations unless we leave a symlink in the incorrect location, or
2. make OpenPAM look in ${LOCALBASE}/lib/security, but that won't help users of existing releases.

[aokblast]

In D50239#1152486, @des wrote:

In D50239#1152212, @danfe wrote:

@des wrote:

OpenPAM does not look for a security subdirectory and never has.

@lwhsu wrote:

Understood, but I am wondering why the original version worked, and all other ports install pam_*.so into lib/security/.

Before we proceed, do we have a definitive answer for these two questions?

The first is not a question, it's a statement.

The answer to the second is that even though the module is in the wrong location, it still works if you provide the full path in your PAM policy.

We can either:

1. fix all ports that install PAM modules to install them in the correct location, but that will break existing configurations unless we leave a symlink in the incorrect location, or
2. make OpenPAM look in ${LOCALBASE}/lib/security, but that won't help users of existing releases.

I discover you requries a change to this patch. What is the request change you want me to do? I already use softlink.

[des]

In D50239#1152534, @aokblast wrote:

I discover you requries a change to this patch. What is the request change you want me to do? I already use softlink.

Not intentionally. Probably a bug in Phabricator.

[des]

cf. D50626

[aokblast]

Close it as the maintainer decide to fix at the src side.