Bug 221613 - pw expire_days have a bug
Summary: pw expire_days have a bug
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 10.3-RELEASE
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-08-18 20:06 UTC by Andres Montalban
Modified: 2020-10-01 20:39 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andres Montalban 2017-08-18 20:06:11 UTC
Hey guys,

I'm using the following /etc/pf.conf configuration:

  home     /home
  homemode   027
  defaultshell   /usr/local/bin/bash
  defaultclass   default
  password_days  60

According to [1] "expire_days	  days after which account expires"

And:

 The expire_days and password_days are used	to automatically calculate the
     number of days from the date on which an account is created when the
     account will expire or the	user will be forced to change the account's
     password.	A value	of `0' in either field will disable the	corresponding
     (account or password) expiration date.

However what the password_days parameter does is to include that in the /etc/passwd:

  amontalban:*:1003:1006:default:60:0:Andres Montalban,None,None,None:/home/amontalban:/usr/local/bin/bash

And according to [2] the expire parameter (60 in the above line) should be:

The expire	field is the number of seconds from the	epoch, UTC, until the
     account expires.  This field may be left empty to turn off	the account
     aging feature; a value of zero is equivalent to leaving the field empty.

So it's clearly a bug when pw generates the user as it should put the epoch time in that field.

[1] https://www.freebsd.org/cgi/man.cgi?query=pw.conf&sektion=5&n=1
[2] https://www.freebsd.org/cgi/man.cgi?query=passwd&apropos=0&sektion=5&manpath=FreeBSD+10.3-RELEASE&arch=default&format=html
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2017-08-19 06:42:07 UTC
ITYM pw.conf, not pf.conf?
Comment 2 Andres Montalban 2017-08-19 14:15:59 UTC
(In reply to Mark Linimon from comment #1)
Correct sorry I meant /etc/pw.conf
Comment 3 Andrew Daugherity 2020-10-01 20:39:20 UTC
I can confirm this is still an issue on 12.1.

I have in /etc/login.conf:
default:\
        [...]
        :passwordtime=1y:\
        :warnpassword=7d:

But this was not applied to newly-created accounts (regardless of using either adduser or "pw useradd"), which had 0 in the sixth field of master.passwd, meaning password expiration was ignored.

I first tried editing adduser.conf, adding 'upwexpire=1y', but then creating users failed with the error "pw: Invalid date".  (I guess adduser calls pw useradd internally, which makes sense.)  I then tried the example straight out of adduser.conf(5) of 'upwexpire=91d', which also fails.  A bare number does work, but gets copied directly to the change field of master.passwd, rather than being converted to epoch-relative time.

Similarly, setting 'password_days = 365' in pw.conf, makes users get a literal 365 in master.passwd, just like Andres' report.


Workaround: Don't set password_days in pw.conf, but immediately after user creation, set the expiration time with "pw usermod -p"; date(1) can help convert relative dates to the epoch format, e.g. for 60 days in the future:
    pw useradd $USER ...
    pw usermod $USER -p `date -v +60d +%s`