Gentoo Archives: gentoo-dev

From: "Diego \\\"Flameeyes\\\" Pettenò" <flameeyes@×××××××××××××.de>
To: gentoo-dev@××××××××××××.org
Subject: [gentoo-dev] The Pluggable Hell - aka Linux-PAM and non-linux gentoos
Date: Mon, 28 Mar 2005 13:48:31
1 Hi,
2 as I've already posted on gentoo-bsd mailing list[1], I'm trying to get
3 gentoo/fbsd behave the same as gentoo/linux wrt pam stuff.
4 Main problem is that g/fbsd and g/linux uses two different pam
5 implementations: Linux-PAM and OpenPAM.
7 Also if PAM should be quite standard, most linux distribution (gentoo
8 included) ships Linux-PAM with some added modules, one of which (pam_stack)
9 it's useful to avoid copy-and-pasting pam configuration files for different
10 services, using the same authentication methods of another service (usually
11 system-auth).
12 This is useful, as allow to change a single configuration file to get all the
13 services use a defined authentication scheme, but it has a big drawback: it's
14 not portable, depends on the internal structure of Linux-PAM library.
15 If this could be acceptable for a linux only distribution, with gentoo, the
16 problem is quite serious.
18 Ok we could switch g/fbsd to use Linux-PAM, as Linux-PAM is multiplatform, in
19 spite of its name, but this won't fix the problem, as g/osx would have the
20 same problem: macosx's pam implementation is compatible with openpam,
21 linuxpam and so on, but it doesn't support pam_stack.
23 Now, solution of that is quite simple: just don't use pam_stack, and convert
24 all the pam configuration file to duplicate the default system-auth
25 authentication scheme. If someone needs to change the way system-auth works,
26 adding ldap, samba or something like that for authentication, they should
27 also be able to change the needed other services, such as sshd, ftpd, pop3
28 and imapd stuff.
30 This is not the only thing needed to fix everything up. All the packages which
31 depends on sys-libs/pam should be changed, as g/fbsd, g/osx and other
32 g/non-linux can have other implementations of pam. My suggestion is adding a
33 virtual/pam which could be used, so that g/osx will provide it directly,
34 g/fbsd could provide it via its own packages (or using an openpam package,
35 which could be used on linux, too), and linux still can use sys-libs/pam.
37 Also, it could be better rename sys-libs/pam into sys-libs/linux-pam: also if
38 the name isn't restrictive, that's the right name for them: it's not "The
39 PAM".
41 [1]
42 --
43 Diego "Flameeyes" Pettenò