Bart Blanquart schrieb: > Now, the goal is to avoid the need to deal with modified pam.conf or > equivalent files when upgrading a system (or patching or similar). > > The easiest way to go about that seems fairly simple: >
One aspect that seems to be unaccounted for in much of this discussion is that there are three sources of modifications to PAM configuration: 1. System updates and upgrades 2. Customer policy 3. Layered/ISV software Changes of the first type should mostly happen in /usr and that is part of what the include/pam_user_policy changes make possible. Changes of the second type traditionally happen in /etc, but preferably allow use of a centralized database/mechanism. Changes of the third type don't have a well defined place. Typically they have to be done by changing things in /etc, but without interfering with customer policy and without impeding proper system, evolution. It helps untangling these types of changes if system provided default configuration in /etc never changes and uses an indirection into /usr to pick up any changes of 'system' origin. Forbidding modification of files in /etc and confining all non-system change to network-capable, wholly customer-controlled databases blocks out ISVs. An example of this third type is Sun Ray Server Software, which is a layered product from within Sun, but in the same situation as a third-party ISV product would be. SRSS today applies the following kinds of changes to PAM configuration: a) Add its own modules to existing system service stacks, honoring existing customer policy. b) Create new service stacks, that derive from an existing system service stack (honoring customer policy) and add some extra modules. c) Create new, customizable service stacks with a default configuration (And yes: maintaining the pam.conf-munging code for this is not fun) All of this customization should be applied (effectively) when the product is installed and undone when the product is uninstalled. Adding services (b)+(c) would be somewhat easier to do and better decoupled, if everyone were using /etc/pam.d/ instead of /etc/pam.conf - but when both exist and are being used by customers, this makes ISV logic even more complicated as it has to cope with both cases. (This is what we currently (have to) do in our scripts for Linux...) Changes of type (a) and (b) are helped by existence of an 'include' mechanism, but changes of type (a) can't be done without modifying at least one pre-existing file. > - we ship a pam.conf that contains a binding entry with pam_user_policy > and a second binding entry with pam_system_policy and nothing more > > - the first module looks for whatever file in /usr/lib/security it's > being pointed to if the appropriate pam_policy exists in the user's > attributes or profiles, in its absence it returns PAM_IGNORE > > - the second module looks for whatever file in /usr/lib/security that is > specified in host_attr(4) for the local host. If this is absent it falls > back to "any.conf" (or some other sensible default) > > Editing pam.conf or any of the files we ship in /usr/lib/security is not > supported, and upgrading/patching/... will either overwrite them or > complain (whatever the packaging system does in such cases), but it > won't merge or modify the file contents. > > If someone wants to specify a local PAM stack one needs to walk through > for accessing this system a simple change to host_attr(4)'s pam_policy > to point it to a locally created and customised file would do. > How does the installer (or configuration tool) of some ISV or add-on software (rather than any 'someone') add a module to the authentication stack of all (or multiple) services? Obviously a change can apply to the current host only, as the software may not be present on other machines. And how does one (either an administrator or the mentioned installer) add a module that must be at the top of the stack? As an example, SRSS has PAM modules that need to be placed before any existing modules that might prompt for a user name: the modules preset/populate the PAM_USER item or even shortcut authentication (via sufficient flag) without even beginning the 'usual' login authentication. Even in the latter case the module needs to be stacked, as it acts only conditionally, depending on context and dynamic configuration. [...] > Having unmodifiable pam.conf and friends solves the no-editing problem > for any module, not just for pam_authorized, as modifying the local > policy requires creating a local file (which we thus won't touch) and > updating a single field in host_attr(4) (a field we won't touch and as > it's a key=value pair it's easy enough to avoid even if we need to add > or modify other key=value pairs for that entry). > > As long as host_attr(4) is not yet implemented it could be reasonable to > have a PAM_POLICY= in policy.conf, which would be used by pam_system_policy. > Requiring modification of host_attr/policy.conf works for policy customization by administrators. It doesn't work for (automated) addition of enriched functionality or new services by add-on software. - J?rg -- Joerg Barfurth phone: +49 40 23646662 / x66662 Software Engineer mailto:joerg.barfurth at sun.com Desktop Technology http://reserv.ireland/twiki/bin/view/Argus/ Thin Client Software http://www.sun.com/software/sunray/ Sun Microsystems GmbH http://www.sun.com/software/javadesktopsystem/
