Hi Sam, On Sat, 12 May 2001, Sam Hartman wrote: > So, both the Linux-PAM and Solaris documentation tell authors to call > pam_open_session before pam_setcred. I don't understand why this > would ever be useful and have examples of cases where it would be a > bad idea. If memory serves, the primary motivation for this arrangement was that pam_open_session() might need to be called with root privileges, and pam_setcred() might do something that would change the unix privileges of the running process. If that's the case, it certainly seems to no longer be necessary; but there may be other reasons why this order was chosen. Regardless, I think that having a deterministic sequence for these function calls is important, particularly for the more complex PAM modules: I don't know if one sequence is better than the other, but I think a lot of module and application writers now depend on the behavior specified in the documentation. > In particular, I'm looking at the interactions between Kerberos > modules and session modules that depend on access to network > credentials. It seems that the Kerberos module should make tickets > available (write them out to disk as the user) in the pam_setcred > call. This seems an appropriate use of the call and works quite well > in most cases. Yes, I've certainly understood this to be the proper use of pam_setcred() from Kerberos modules. > But then it seems that it would be a session level activity to mount a > homedir, or create a homedir, or in my case let AFS know about tokens. > None of these activities have anything to do with authentication, but > all of them could depend on having access to network authentication > made available in setcred. For example, I could be using a networked > filesystem with authentication to mount the homedir. I could desire > to log into a database to get information on the initial contents of > the homedir, authenticating to the database with the network identity > of the already authenticated user. In the AFS case I need the > credentials to convert them into tokens. My understanding of non-filesystem-based credentials caches is fairly low, but I was under the impression that with Kerberos 5 it's possible for the PAM authentication module to make the TGT available to the process before it's written out to its final file location. This means that, with a proper interface (i.e., using pam_getenv()), libpam-openafs-session could make use of the Kerberos credentials before pam_setcred() is called. > I'll take a moment to counter the argument that AFS tokens have > something to do with authentication. It is true that Transarc ships a > PAM module that uses AFS tokens for authentication. This > authentication is very weak (about the same level as NIS) because the > client never authenticates the identity of the AFS server. In the > case where you have Kerberos infrastructure and are just using AFS as > a filesystem, you don't care about AFS for authentication, and just > want to make the credentials available to the kernel. It's true that AFS has no authentication value, but it's also the case that this module's functionality -- establishing credentials for filesystem access -- can be seen as falling snuggly within the responsibilities of the pam_setcred() function. An authentication module which returns an unconditional PAM_IGNORE to pam_authenticate() and does all the real work in pam_setcred() is therefore not out of the question, IMHO. > So, I am maintaining a module (libpam-openafs-session) for Debian that > attempts to get AFS tokens. Previously it only worked as a session > module, but I'm trying to add authentication support to the module for > setcred. I'm running into the annoying problem that there appears to > be no valid configuration for the module. > I really want the Kerberos module to be sufficient because I want to > allow users with local accounts to use pam_unix.so, so I need to make > pam_unix.so be more than just optional so people with neither local > accounts nor Kerberos authentication will fail. However, the openafs > auth setcred call needs to happen after the Kerberos setcred call so > it can get to the credentials. Sadly, if the sufficient Kerberos > module succeeds no other modules will be tried. To me, this is a > fairly strong argument that AFS tokens cannot be an authentication > activity--you want them to get set up even if you have already > established sufficient authentication beforehand. Do either of these configurations meet your needs? auth required pam_krb5.so auth optional pam_openafs.so auth sufficient pam_unix.so try_first_pass or auth sufficient pam_unix.so auth requisite pam_krb5.so try_first_pass auth optional pam_openafs.so My own impression is that the second case provides the semantics usually desired by an administrator (give precedence to local accounts, ignoring network databases on success), but there's always the possibility that you want to query the network database first so that those with accounts in both databases aren't locked out from using network filesystems. This could lead to the simple policy that users who have network credentials shouldn't have local passwords, but even that may not be desirable to the admin for whatever reason. In that case, I think the first config above may do the right thing, assuming a pam_openafs module that returns PAM_IGNORE from pam_sm_authenticate(). I don't suggest taking my word for it, though, as my memory is spotty when it comes to the exact behavior of the PAM configuration directives; it may be that both pam_krb5 and pam_unix must succeed in this configuration. Regards, Steve Langasek postmodern programmer
