I always wondered why the gentoo PAM package comes along with all those third-party pam_modules from redhat guys.Obviously it was because pam_console and pam_pam_stack were used overall in the default pam configs. But do we really want that ugly pam_console? As it seems nobody really likes it ;). It definitly causes more trouble than it is effectivly useful for most users. It also brings that annoying glib dependency to pam. Every distro besides RH seems to avoid it like hell. Also gentoo is trying to get rid of it since quite some time now.(See #31877) Second commonly used module is pam_stack. As of pam-0.78 it is obsolet as PAM now comes with a nice "include" directive which does everything pam_stack does. The other modules are more exotic ones like pam_chroot,pam_postgresok etc., not necessary for normal usage. So no more reasons to include all those redhat modules. Beside those reasons its quite a uncommon policy to put the official lib and third-party add-ons into one ebuild. All other pam_modules got their own ebuild. Im currently testing pam-0.78 on my machine and hacking together some ebuilds with separated Linux-PAM, pam_stack, pam_console, etc. If there is any interest i can post them later this weekend if I got it running. Thx Imago
got things running, take a look to get an idea what i meant http://imago.devinity.de/~pam/
A word of praise for this project, we really need something like this. Thanks Peter! Unfortunately, at the moment we lack someone who has the time and the skill to implement it...
glad to hear that i'm not the only one who wants this ;) but its seems at bit tricky to make this change to the portage tree *without* breaking to much systems.So the one-step solution i put together in #1 is maybe not the best idea: - first all packages who place a file in /etc/pam.d/ shouldnt use pam_console by default( which is already work in progress: bug #31877) - same has to be achieved for the pam_stack module-> but before that can be adressed: pam has to be upgraded to 0.78 to use the new include statement instead of pam_stack. - for pam-0.78 see: bug #73082. (its quite a painful work, dealing with all these patches) so there are some steps to be done first.
As I've posted to gentoo-dev, for g/fbsd pam_stack must be deprecated asap. Linux-PAM 0.78 is here, so that problem should be ok (why the bug is still open, anyway?). pam_console and other modules could be moved out of pam ebuild i think, as anyway they are use-flagged now, I'm waiting for comments on gentoo-dev and then I'll start hacking at pam ebuild trying to remove the external modules out of it (and clean it up a bit..) About avoiding breaking the tree, the solution I've posted on gentoo-dev (depending on || ( >=sys-libs/linux-pam-0.78 virtual/pam ) ) should make the trick. If you are subscribed to gentoo-dev, join the discussion about it as it's the major blocker at the moment to make g/fbsd work with out-of-the-box packages.
Yeah, this is the plan, and moving towards it (why I keyworded the extra crud we could start to punt), but it wont be over night.
