The Puppet Labs Issue Tracker has Moved:

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using See the following page for information on filing tickets with JIRA:

Bug #11094

ruby-libshadow not being used on RHEL 6

Added by Dan Lowe over 4 years ago. Updated over 3 years ago.

Status:AcceptedStart date:11/30/2011
Priority:NormalDue date:
Assignee:-% Done:


Target version:-
Affected Puppet version:2.7.6 Branch:
Keywords:useradd passwords

We've Moved!

Ticket tracking is now hosted in JIRA:


To be honest, I am not sure if this should be a bug or feature request, but my reading of the documentation makes me think it’s a possible bug.

On my Solaris 8 and 10 systems, I have Puppet 2.7.6 running with ruby-libshadow, and users are added as expected, including their shadow passwords being handled.

On RHEL 6, the users are being added properly, but during an audit we determined that there is information leakage during the add process. The password hash is being supplied to useradd via the “-p” flag. (Presumably this is also the case with usermod when the user already exists at the time of password set/change.) That creates a small but extant leakage where the hash is exposed to any user on the system via the process table (if only briefly).

My understanding is that when libshadow is installed, Puppet is supposed to use it to handle shadow passwords, instead of using user{add,mod} -p. Is this intentional behavior, or is it abnormal that libshadow is not being used?

I wrote a wrapper around useradd to capture the arguments it was passed, here is an example test user that was added.

‘-s’ ‘/bin/bash’ ‘-u’ ‘9998’ ‘-g’ ‘root’ ‘-c’ ‘Dan Lowe’ ‘-d’ ‘/home/dantest8’ ‘-p’ ‘EAY9JzzcL3kSz’ ‘-M’ ‘dantest8’

libshadow is installed on this system.

$ gem list | grep shadow libshadow (1.0.0)


#1 Updated by Josh Cooper over 4 years ago

  • Status changed from Unreviewed to Investigating

Could you verify that puppet is able to load the libraries:

$ ruby -e "require 'puppet'; puts Puppet.features.libshadow?"

#2 Updated by Dan Lowe over 4 years ago

Yes, it is loading properly.

$ ruby -rpuppet -e 'puts Puppet.features.libshadow?'

#3 Updated by Josh Cooper over 4 years ago

  • Category set to security
  • Status changed from Investigating to Accepted
  • Keywords set to useradd passwords

So the solaris user_role_add provider does not leak the hashed password because it directly writes to /etc/shadow (using a tempfile). The useradd provider on the other hand only uses ruby-shadow to read the password entries — when determining if the passwords are in sync. However, when setting the password, it passes it on the command line, and has apparently done this forever. I’m not sure why it’s not using Shadow::Passwd.putspent to set it (with appropriate locking), but clearly it should.

#4 Updated by Dan Lowe over 4 years ago

Since Solaris also provides putspent(), sounds like a possible opportunity to factor out that Solaris-specific code…

Also available in: Atom PDF