kukuk at suse.de
Thu Oct 26 02:28:23 PDT 2006
On Wed, Oct 25, Theodore Tso wrote:
> On Mon, Oct 23, 2006 at 10:35:55PM -0700, Leibowitz, Michael wrote:
> > Can I make an LSB compliant PAM module? PAM isn't specified, so I guess
> > I need to bundle PAM. I could probably get away with not doing this
> > because ABI compatibility is generally easier for plugins. Now, I need
> > to use my bundled version of PAM. That means manipulating a bunch of
> > files that are not in my /opt/vendor/foobar directory. If I understand
> > correctly, the LSB answer is that it is now the sysadmin's job to make
> > it work, and LSB cannot permit the package to automatically manipulate
> > the system.
> Actually, PAM is specified in the LSB.
Missing parts are:
Why do we have pam_getenvlist(), but not this two functions?
This does not make much sense to me. We should add them.
This functions are only for modules and not used very often.
If we wish to really support modules, we should add them.
Module only, but can be replaced with the existing pam_get_item()
So in theory it should be already possible to write LSB conform
PAM modules. The only problem I see is, that this modules need to
be installed in /lib/security, and that ISVs are not allowed to
> What isn't specified is how to manipulate the various files in
> /etc/pam.d, and the reality is that the layout of those files are
> different across different distributions.
This is only a problem if the LSB application wishes to enable
its own PAM modules. Which is even in a well defined environment
nearly impossible. See below.
> Worse yet, depending on what's in the file, it's hard
> to know exactly in what order to insert a particular pam module in the
> middle of a file like /etc/pam.d/login.
It is not only hard, it is impossible. Some month ago I did a
research project how to add new modules on a distribution upgrade
to such PAM config files. The environment was very well defined,
no surprises possible. The result was that it is only possible
for some well defined scenarios, at the moment where the admin
changed the order, added an unknown module or modified the options
it is not possible anymore (who is interested, the result is the
pam-config package on openSUSE 10.2).
So for an ISV it is impossible to develop a mechanism, which works
on all LSB complaint distributions.
> If we want to fix this, it's going to be painful, because the
> distributions have already diverged on what's in /etc/pam.d. But that
> means ISV's that want to provide pam modules and have them be
> automatically configured are suffering already today, so maybe that's
> a worthy project for us to consider.
The distributions haven't really diverged. The syntax is fix, the
names of the PAM config files are mostly defined upstream. So the
biggest difference is, that some distributions uses "common-*" files
to include (Debian/SUSE), while the Red Hat based/clones use system-auth.
Solveable with Symlinks.
If you speak about the content of this files: Yes, this diverge even
on the same distribution depending on what the Admin configured
(Active Directory Client, LDAP, NIS, or what else).
But what is missing in LSB is, which modules can the ISV be expect
to be installed? And who defines how this modules should behave?
This is a big problem.
Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk at suse.de
SUSE LINUX Products GmbH Maxfeldstr. 5 D-90409 Nuernberg
Key fingerprint = 8C6B FD92 EE0F 42ED F91A 6A73 6D1A 7F05 2E59 24BB
More information about the lsb-discuss