Bug #7442

User provided password age bug on Solaris with 2.7.0.rc2

Added by Gary Law about 1 year ago. Updated 11 months ago.

Status:Accepted Start date:05/07/2011
Priority:Normal Due date:
Assignee:- % Done:

0%
Category:-
Target version:-
Affected Puppet version: Branch:
Keywords:
Votes: 1

Description

Hi

Applying the following:–

user { 'puppet':
  ensure           => 'present',
  comment          => 'Puppet',
  gid              => '52',
  home             => '/var/lib/puppet',
  password         => '!!',
  password_max_age => '-1',
  password_min_age => '-1',
  shell            => '/bin/true',
  uid              => '52',
}

(known good on Darwin and CentOS) fails on Solaris:

$ sudo puppet apply /etc/puppet/manifests/site.pp 
glaw@sv01:~ $ sudo puppet apply /etc/puppet/manifests/site.pp 
prtconf: devinfo facility not available
err: /Stage[main]/Puppet/User[puppet]/password_min_age: change from  to -1 failed: Could not set password_min_age on user[puppet]: Execution of '/usr/bin/passwd -n -1 puppet' returned 6: passwd: Invalid argument to option -n
Invalid argument to option

notice: /Stage[main]/Puppet/User[puppet]/password_max_age: password_max_age changed '' to '-1'
notice: Class[Puppet]: Dependency User[puppet] has failures: true
warning: Class[Puppet]: Skipping because of failed dependencies
notice: Stage[main]: Dependency User[puppet] has failures: true
warning: Stage[main]: Skipping because of failed dependencies
notice: Finished catalog run in 0.13 seconds
glaw@sv01:~ $

I think that the correct command for passwd in this case would be /usr/bin/passwd -x -1 puppet

But in any event the provider doesn’t seem to report on it, so even setting this correctly by hand doesn’t cause puppet to apply the config without error:

$ sudo puppet resource user puppet
prtconf: devinfo facility not available
user { 'puppet':
  ensure   => 'present',
  comment  => 'Puppet',
  gid      => '52',
  home     => '/var/lib/puppet',
  password => '!!',
  shell    => '/bin/true',
  uid      => '52',
}

Gary

History

#1
Updated by Ben Hughes about 1 year ago

  • Status changed from Unreviewed to Accepted

Thank you Gary for doing all the leg work. That is what we need to do.

From the Sunny Solaris man pages:

     -n min              Sets minimum field  for  name.  The  min
                         field  contains  the  minimum  number of
                         days between password changes for  name.
                         If min is greater than max, the user can
                         not change the password. Always use this
                         option with the -x option, unless max is
                         set to -1 (aging turned  off).  In  that
                         case, min need not be set.
[...]
     -x max              Sets maximum field  for  name.  The  max
                         field  contains  the number of days that
                         the password  is  valid  for  name.  The
                         aging for name is turned off immediately
                         if max is set to -1.

Trying on a real bonafide Solaris machine:

[root@slave10:~]# /usr/bin/passwd -n -1 ben          
passwd: Invalid argument to option -n
Invalid argument to option
[root@slave10:~]# /usr/bin/passwd -x -1 ben
passwd: password information changed for ben
[root@slave10:~]# /usr/bin/passwd -x -1 -n -1 ben
passwd: Invalid argument to option -n
Invalid argument to option

In the case of maximum_age being -1, we should ignore minimum_age it seems.

#2
Updated by derek olsen 11 months ago

As a side not this is not specific to 2.7.X as the same behavior is seen in 2.6.8.

The problem stems from the fact that if password aging is disabled for a user on solaris there is no artifact in the shadow file that indicates that. The lack of any number in the fifth field of the shadow line means password aging is disabled. It would seem that for solaris when the provider parses the shadow entry and compares the fields to what’s requested in the manifest the handling for password aging should have an additional bit of logic. If the 5th field in the shadow entry is empty/null and the manifest requests “password_max_age => ”-1" then nothing should be done.

This manifest will get applied during every puppet run.

user { "filbert":
  password_max_age => "-1",
  }

First I verify that password aging is currently not set for the user. This can be done with the passwd command or by looking at the shadow file.

passwd -s filbert
filbert   LK  

grep filber /etc/shadow
filbert:*LK*:::::::

Then apply the manifest which shouldn’t do anything as password aging is already disabled.

puppet apply pastest.pp 
notice: /Stage[main]//User[filbert]/password_max_age: password_max_age changed '' to '-1'
notice: Finished catalog run in 0.16 seconds


puppet apply pastest.pp 
notice: /Stage[main]//User[filbert]/password_max_age: password_max_age changed '' to '-1'
notice: Finished catalog run in 0.16 seconds

I’d be happy to provide any further info/clarifications if required. Thanks. Derek.

#3
Updated by Mark Heily 11 months ago

I agree with the previous comment that setting password_max_age => ‘-1’ causes the resource to continually be reapplied in Solaris. As a workaround, I’m using the value of ‘99999’ instead of ‘-1’ so passwords will expire every 273 years :)

Also available in: Atom PDF