[lsb-discuss] Packaging

Theodore Tso tytso at mit.edu
Wed Oct 25 21:13:51 PDT 2006

On Wed, Oct 25, 2006 at 08:39:04PM -0700, Wichmann, Mats D wrote:
> Turns out the module interface is not specified either, so you can't
> make a compliant module, but you can write a program that /calls/
> PAM in a compliant way.

Well, technically speaking, as long as the module doesn't call any of
the PAM helper functions (yeah, it would be a pretty trivial
module... humor me), technically an LSB application which shipped such
a PAM module would be LSB complaint, even if the PAM module screwed up
one of the function signatures which is called by the PAM

> (yes, I understand PAM was just an example anyway. it's an
> interesting example because it points at an issue that isn't
> cleanly handled by the current LSB/FHS filesystem namespace protection
> rules or installer rules - that is, plugin architectures that
> require some files, either plugins or configuration files that
> say where to find the plugins, in a very specific place, rather
> than where FHS says you can install 3rd-party files. but that's
> kind of a different topic...)

Yep.  It also illustrates the sort of restrictions we would need to
apply against applications that want to deliver a shared library
object that purports to offer a particular service, such as a PAM
module.  We currently don't have a framework for saying, "if a shared
library is claiming to be a XXX module/plugin", here are the
interfaces that it must provide, with the following semantics.  All we
have is a requirement that an application must only use symbols which
are documented in LSB standard --- hence my claim that a PAM module
that didn't use any of the PAM helper functions would be LSB
compliant, even had a buggy set of function prototypes which it

Is this something we should fix.  Probably.  How high priority is it?
I dunno; how many ISV's have products that want to provide custom PAM

						- Ted

More information about the lsb-discuss mailing list