Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I am writing my own PAM module that will be part of an application that I am developing, but I'm not sure exactly where to put it. My module basically does network-level authentication (with other mojo of course) similar to LDAP.

There are a lot of config files in my /etc/pam.d/ directory, and I know what most of the services do (except a couple, like atd, polkit, ppp). I assume that authentication with PAM stack goes something like this:

  1. Runs stack based on service name (if a config file exists)
  2. If not authenticated, fall back on common-*, where * is the module-type (auth, account, etc)
  3. Return success or fail to calling application (and any other data of course)

Am I correct in this assumption? Do all platforms have common-auth, common-account, common-password, and common-session?

If so, I was thinking about just putting it at the top of common-* as a sufficient module so that on failure the regular PAM stack would be left unaffected. This is particularly advantageous because I can programmatically do this on software install.

Am I missing any potential security vulnerabilities?

I couldn't find very good documentation on where to integrate custom PAM modules or security issues surrounding where to put modules.

share|improve this question
2  
The whole point of PAM is to decouple actual authentication procedures from applications, so to let sysadmins configure them separately. If your application depends on your authentication module, this might be an indication that you are abusing PAM. –  Riccardo Murri Jun 19 '11 at 22:58
    
Well, my application is a daemon that syncs a user's account with the network if the logged-in user is a network user. I think as long as I don't allow communication between the daemon and the PAM module I should be ok. –  tjameson Jun 20 '11 at 2:48
add comment

1 Answer

up vote 5 down vote accepted

When you call into Linux-PAM for some authentication procedure, there is always one and only one stack that is run.

The stack definition is looked up in these places; the first successful attempt determines which file is read:

  1. the file in /etc/pam.d named after the application "service name" (e.g., sshd or gdm), or

  2. the file /etc/pam.d/other if no service-specific file exists, or

  3. the file /etc/pam.conf if directory /etc/pam.d does not exist.

See the documentation for function pam_start for details.

The common-* files are a convention followed by many Linux distributions but are not mandated by the PAM software itself. They are usually included by other PAM files by means of @include statements; for instance the /etc/pam.d/other file on Debian has the following content:

# We fall back to the system default in /etc/pam.d/common-*
@include common-auth
@include common-account
@include common-password
@include common-session

The same @include statements may be used by service-specific file as well, and -indeed- they are in the default configuration on Debian. Note that this is a matter of configuration: a sysadmin is free to change the file in /etc/pam.d not to include any common-* files at all!

Therefore: if your PAM module is specific to your application, create an application-specific service file and call the module from there. Do not automatically add a module to other services' PAM file nor to the fall-back others file, as this may break other applications installed on the system. Management of the PAM software stack is a task for the system administrator, not for the application developers.

share|improve this answer
    
This really cleared stuff up for me. Do some distributions use the common-* files as a backup for the service-specific config files? When I put my module in common-auth, it was run even when running sudo. –  tjameson Jun 20 '11 at 2:51
    
@tjameson I've updated the answer with more details on the common-* files –  Riccardo Murri Jun 20 '11 at 12:29
    
Ok, thanks!! Now I understand it all. I thought that perhaps my distribution had a custom fall-back procedure build in to their version of PAM or something. Thanks for clearing this up. –  tjameson Jun 20 '11 at 19:01
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.