Ok many people today have seen bugs related to "openpam compatibility fixes". I think it's better explain what's going on, why I'm filling them and why some of them are marked "openpam and amd64 compatibility".
For who doesn't remember, OpenPAM[1] is the PAM implementation used by FreeBSD, so also by Gentoo/FreeBSD project. OpenPAM is a base framework which actually doesn't provides modules, but just libpam and related utils. It's lighter but usually compatible with sys-libs/pam (Linux-PAM actually). Using PAM, many packages just uses pam_stack.so to provide the same authentication scheme as base login (system-auth), but this makes some things a bit complex. This because pam_stack.so is a non-standard module which is created by RedHat that gentoo "inherited" and which is used by many pamd files in the tree. OpenPAM and Linux-PAM 0.78 provides the same functionality of pam_stack.so as "include directive", so something like auth required pam_stack.so service=system-auth can be changed in auth include system-auth and works fine both on >=sys-libs/pam-0.78 and openpam (G/FBSD). I'm walking in the tree to fix packages which uses pam_stack.so and submit bugs for them, so to use include directive. Some of them just uses a pamd file which includes system-auth, in this case I reported them to use pamd_mimic_system which is a function I wrote in pam eclass[2], which is still not in portage as it's waiting for Azarah's review. This because using that function you save from have one more file in the tree. Main issue with changing the files is that the minimum version required by the include directive for sys-libs/pam is 0.78, which is in ~arch for now. This means that packages needs to revbump to fix the dependency. The version requirement is already taken care by virtual/pam virtual which is provided by the right ebuilds. Now, why amd64 is involved in this? Many pamd files specifies the entire path to the modules they use, so for example, to use pam_stack, they use /lib/security/pam_stack.so . This is valid now, but in no-lib32 profile for amd64, where /lib points to the 32-bit version instead of 64-bit as it does now, it will fail. Avoid using hte fullpath but just the pam module's name, fixes the problem both for amd64 and for openpam (openpam installs modules in /usr/lib). This is ok for the pamd files in tree, for which I'll take care to report fixes to maintainers, but the problem is for packages which doesn't install the pamd file from the tree but from their own sources. In those cases, I can't do much, as I don't know all the packages in the tree to fix them, and I the ones I use I already take care of. So if you are a maintainer who knows that your package installs a pamd file, drop a line to me (mail or irc) and I'll take care of looking at it for eventual openpam/amd64 compatibility fixes. This can also be done in a second moment for g/fbsd, but there can be problems with amd64, and fixing soon all the packages is still important. Oh please note that not just pamd files needs fixes for G/FBSD, but also pam modules, so I may need to take a look also to some packages which installs pam modules. A full tracker for pam issues with g/fbsd is on bug #93119[3]. [1] http://www.openpam.org/ [2] https://bugs.gentoo.org/show_bug.cgi?id=93118 [3] https://bugs.gentoo.org/show_bug.cgi?id=93119 -- Diego "Flameeyes" Pettenò Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64) http://dev.gentoo.org/~flameeyes/
pgpUpA1OXcXCr.pgp
Description: PGP signature
