U-Bolt currently consists of NSS and PAM modules, summarized as follows.
See doc/*.txt for deeper details.
A presentation to the OSG CIC group was given on 22 Feb 2013 covering much
of the motivation, behavior, and implementation of the U-Bolt tools. You
can find the slide deck here:
nss_identity provides a means of fabricating POSIX nameservice entries
based upon information present in the request and (perhaps) elsewhere
within the nsswitch framework, but without reference to an external
source of authority. This is primarily useful for fabricating
identities: a 1:1 mapping of numeric IDs to predictably corresponding
nss_filter is a preliminary effort at an NSS library that authoritatively
sources nothing, but can filter results from other libraries. It is
currently quite limited: it is capable of filtering only passwd, and it
can only perform one type of filtering: replacing a '&' token with the
user login ID (``pw_name``). This is sufficient proof of concept and
adequate to our current need, but it should be extended:
* because it can be, and it is not complete;
* because it only offers one type of filter that is hardcoded.
pam_provision.so is a PAM module to assist in automatic account
provisioning. It assumes that some kind of functioning POSIX account
information is available through the name service switch: nss_files,
nss_ldap, whatever. If you can provide the account information,
pam_provision can do whatever is necessary on the local system to
make the account function. This could be as minor as creating a home
directory, or it could involve other elements of session management.
Pam_provision's only job is to call the program you tell it to. This
provisioner program can be a shell script or a program in any other
language. An example provisioner written in Python is included with
pam_provision.so was developed on and for Solaris, and has been
ported to Linux. It should work for other PAM platforms as well.
Astute readers will wonder what's wrong with pam_exec, and why we
think we need something that does basically the same thing. There
are two reasons: (a) pam_exec was not available when pam_provision
was developed, and was not portable to Solaris when it did arrive;
(2) many releases of pam_exec, including all those through RHEL 5,
did not support passing context information to the executed program
in any fashion, as with pam_provision's %u, %s, etc variables. Later
versions of pam_exec do this via the environment, and pam_provision
now supports this too.
pam_provision is not really necessary as of RHEL 6, but is included
here for historical reasons, and because some of its internals will
prove useful for future PAM modules.