Kilala.nl - Personal website of Tess Sluijter

Unimportant background
Login
  RSS feed

About me

Blog archives

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

> Weblog

> Sysadmin articles

> Maths teaching

<< 8 / 2025

Revisiting Linux PAM: does authentication really require root access to /etc/shadow?

2025-09-05 20:53:00

Consider this part 2 of a two part series. Here is part 1.

While researching the use of PAM for authentication I was surprised: I thought the PAM API enabled any application to use the local Linux authentication files in an easy and safe way.

Taken literally that statement is true. But it lacks one detail: it doesn't mention the access rights needed by the application!

To my brain "any application" literally meant every application running on Linux. I hadn't considered limitations! I'd thought PAM was an active mediator, but instead I'm now reminded that it's a set of programming libraries. There is no PAM service which performs authentication for you, you have to do it yourself. 

PAM and Apache web server

Because I really can't work with Java, I thought I'd find an example that's closer to my understanding: the Apache web server.

There is more than one Apache module to authenticate against PAM, the most popular being mod_authnz_pam.

I started with a walkthrough like this article on Siberoloji. It's outdated and I needed to make a lot of changes to the workflow (which I will turn into a lab for my Linux+ class!). 

I soon had Ubuntu running Apache, with /var/www/html/private being blocked off by PAM authentication. A curl without --basic immediately leads to a 401 Unauthorized (as expected). Trying the curl with basic authentication and my username and a wrong password also gave the 401. Good. 

But when I tried my username with the real password, I also wasn't let in:

     unix_chkpwd[4159]: check pass; user unknown
unix_chkpwd[4159]: password check failed for user (tess)
apache2[4076]: pam_unix(apache2:auth): authentication failure; logname= uid=33 euid=33 tty= ruser= rhost=127.0.0.1 user=tess

Most assuredly my user is not unknown! It's right there in /etc/shadow

Looking at the code and the documentation for the Apache module, I see that it uses a compiled C binary, unix_chkpwd. The documentation for this tool clearly states that it must be run as the root (uid=0) user account, otherwise you cannot authentication other users than yourself. 

On systems with SELinux, you even need to set an additional boolean to allow the webserver to work with PAM: 

     setsebool -P httpd_mod_auth_pam 1

It still wasn't clicking for me: surely you should be able to use PAM and unix_chkpwd without root access, right?!

And that's when I found a blog post that I had written in October of 2020. It was literally the second hit in Google and Ecosia! I had already done this whole research four years ago! It was also discussed on RedHat support.

As a test, I modified the Apache user account to be in the shadow group:

     sudo usermod -aG shadow www-data

And presto, now I can authenticate with my real username and password.

One final test: the LibPAM proof of concept

I thought I'd give it one final shot! I turned to the PAM developer documentation, which has a very simple demo program to perform a username/password check.

To build the application on Ubuntu, I installed the libpam0g-dev package via APT. I then compiled it by running:

     gcc pamtest.c -lpam -lpam_misc -o pamtest.o

If I run pamtest.o without any parameters, it defaults to user "nobody". And that gives results we've seen before:

     unix_chkpwd[83004]: check pass; user unknown
unix_chkpwd[83004]: password check failed for user (nobody)
pamtest.o[83002]: pam_unix(check_user:auth): authentication failure; logname=tess uid=1000 euid=1000 tty= ruser= rhost= user=nobody

If I run pamtest.o with my username as the argument, it works perfectly.

If I run "sudo ./pamtest.o www-data" and I give it that user's password, it also works. 

Conclusion

Yes, Tess. PAM authentication really does need privileged read access to /etc/shadow. You can't escape it. 

See you in four years, when you've forgotten this again. ;)

Lab exercise: Apache and PAM authentication

I've added a lab exercise to day 14 of my Linux+ class. It walks you through setting up a protected website which uses the local Unix user database for authentication.

The PDF is here on Github, the lab starts on slide number 48.


kilala.nl tags: , ,

View or add comments (curr. 0)

Linux PAM authentication for Java applications

2025-09-05 20:20:00

Consider this part 1 in a two part series. Here's part 2.

One of my students at school, a Java-developer in the Linux Essentials class, asked me a smart question: "could you use the Linux users database for authentication in your Java application?". 

It's a clever idea, since Linux already takes care of secure storage, of password hashing and it has tools for user management. It's not a bad question! So let's discuss the topic, first from the Java side ending with a conclusion and some suggestions. Then in part 2 I'll look more into the Linux side. 

Linux authentication

Yes, Linux offers a standard API for integration with its authentication and authorization implementation, PAM: pluggable authentication modules. A lot of software already makes use of PAM, most notable in your daily life: SSH, su, sudo, FTP and so on. 

But Java and Spring? Not so much.

PAM libraries for Java

Normally, the first thing that I do is to turn to the Maven online registry to see if there's libraries out there that match my search query. Oddly, I didn't find anything at all when it came to Java + PAM

So I dug around a little bit, to see if it's really never been done. I stumbled upon the JenkinsCI Github, who have a plugin which allows you to use local Linux authentication for your Jenkins interface using PAM. The JenkinsCI project people are no newbies, they are experienced developers! Surely they know what they're doing, right?

Diving into their source code, I see they're importing org.jvnet.libpam, which provides classes such as org.jvnet.libpam.UnixUser. Sounds interesting, especially since this plugin had its last update this year.

The weird thing is that libpam is completely unknown on MVNRepo. I find that very strange! Where is it coming from?

After tracking down a lot of historical documents and messages, I find that this library used to be published on https://java.net/projects/libpam4j/.  That website was shutdown in 2016, but luckily the Internet Archive still has the last snapshot available.

The historical snapshot shows the author of the library is/was Kohsuke Kawaguchi, a name that also pops up in the JenkinsCI plugin source code, as kohsuke. Searching Github, I find a repository which seemingly is the modern-day home of the project: https://github.com/kohsuke/libpam4j

The project had its last update seven years ago, in 2018. That was right after a bad security vulnerability was discovered in libpam/libpam4j in 2017.

Because my understanding of the Java programming language is almost nill, I'm having a hard time understanding how it really works. After some reading, I have concluded that the libpam4j Java library is a wrapper around the libC PAM libraries that are native to a number of Unix-like operating systems. Big hints found here in this file and the other implementation files. 

For now I'll accept, in a Jedi-mindtrick-handwave-style, that the library works and does indeed correctly perform PAM authentication. 

Initial conclusion

Yes, there is a Java library that lets you integrate with Linux PAM for authentication and authorization. However, it's somewhat basic and it has fallen into disrepair. It might still work, it might not. The lack of maintenance since 2017 could be problematic. 

Further analysis, advice and warnings

If you'd ask StackOverflow or an AI coding tool like Claude or Copilot about Java and Linux PAM, they would probably serve you a quick and dirty example of using libpam. They won't warn you about the things I described above, nor will it tell you about a few downsides.

Next to the lack of maintenance, there are other considerations you need to make.

  1. In order to use PAM for authentication, your application needs to have read-access to /etc/shadow, the Linux file which has the real user password hashes. Your application must either run as the "root" user with uid=0, or your application user needs to be a member of (secondary) group "shadow". 

    This is undesirable. /etc/shadow holds the accounts of system administrators and of other high privileged processes running on the server. If a flaw in your application allows for RCE (remote code execution) or LFI (local file inclusion), it would allow an attacker to steal all the password hashes of these users.

    More about this in part 2!

  2. If you're building a Java application, it's not likely that the users of your application also need access to the Linux server itself. For example, if you're building an API for data exchange, or a blog or webshop, the people who use the application are likely not employees of your organisation. 

    Mingling their accounts with the others in /etc/shadow means they will have a presence on the server. Unless you prevent logings through means like giving them /sbin/nologin as their login command, these people could login to the server. You really don't want that. 

  3. PAM doesn't just authenticate and authorized, in many cases it also allows users to change their password. This will require write access to /etc/shadow, which definitely needs uid=0 (root) access. Really a bad idea.

  4. In this modern day and age, your Java application will not run on a long-lived Linux server. Instead, it will run in a VM which can be rebuilt frequently, or in a container which gets constantly rebuilt or moved. There will not be a solid local Linux user database in those cases!

Final conclusion

Yes, it's possible. But you really don't want it. Instead use another, modern standard for your authentication. Hook into LDAP, Kerberos, OAuth or if worse comes to worst, build your own database table. 


kilala.nl tags: , ,

View or add comments (curr. 0)

<< 8 / 2025