INACTIVITY_MAXDAYS and wtmps

[Main Group]

Does anybody know how user inactivity is being tracked for use by pam_unix (with the INACTIVITY_MAXDAYS security(4) parameter set to a non-zero value)? This doesn't seem to be well documented, so my first guess is that the PAM module may be checking wtmps(4). If this is the case, what would happen to the inactivity tracking once the wtmps file gets cleared out when it gets too large?

Thank you.

[James R. Ferguson]

Hi:

If the tracking were via the 'wtmp*' files then truncating it or removing it to stop all logging would break the security feature.

If you look at 'shadow(4)' --- the manpages --- you will see that the 'INACTIVITY_MAXDAYS' attribute is related to the 'inactivity'
field of the shadow password file.

Regards!

...JRF...

[Matti_Kurkela · Accepted solution]

The "inactivity" field in /etc/shadow is neither a counter nor a timestamp: updating /etc/shadow is a privileged action, and doing it either daily for each user or at each login would be excessive. This field simply allows setting a specific inactivity timeout value for each user, if necessary.

The question remains, how is the inactivity time tracked by the system?

In Trusted System Mode, the last login time of each user is stored in the /tcb/files/auth// file. When the user logs in, the difference between the last login time and current time is compared to the INACTIVITY_MAXDAYS setting: if too much time has passed since the last login, the login will be rejected and the account will be explicitly flagged as locked.

(This logic is probably embedded in the libraries that manage the /tcb files, so SAM and other tools are able to identify the inactivity-locked accounts whether they've already been explicitly flagged or not.)

As HP-UX is now migrating from Trusted System Mode to the industry-standard shadow passwords, a new place had to be found for those user-specific attributes that are incompatible with the shadow password file format. This place is /var/adm/userdb: see userdb(4) for more information.

Unfortunately the man page does not describe the contents of the userdb directly, but instead refers us to the /etc/security.dsc file. It lists all the data fields of the userdb... and indeed, one of them is the last login time.

The last login time is classified as an internal attribute in the userdb, so it is not displayed by the userdbget command unless you specifically request to view the internal attributes too. For example, the command "userdbget -i -u root" will display all the userdb information about the root user, including the time of the last login (in hexadecimal Unix epoch time format).

MK

[James R. Ferguson]

Hi (again):

Matti provides a number of details that I missed. Thanks, Matti!

There is a detailed discussion of the 'userdb(4)' database and the commands for setting, getting and querying its contents, here, together with the manpages for 'userdb(4)' the commands themselves:

http://bizsupport1.austin.hp.com/bc/docs/support/SupportManual/c01944073/c01944073.pdf

As for the Epoch timestamps, as always, you can decipher these simply by doing:

# userdbget -iu root
root login_time=0x4c10ce06


# perl -le 'print scalar localtime(0x4c10ce06)'
Thu Jun 10 07:35:34 2010

Regards!

...JRF...

[Main Group]

Thank you for the informative reply!

[Main Group]

One more question please: at 11i v2 I believe the userdb(4) is activated with the installation of the SecurityExt bundle. Does that mean that the last login time for all users is baselined at the point when the bundle is installed? I.e. if INACTIVITY_MAXDAYS were set to, say, 45 days, would accounts start to hit that time point 45 days after SecurityExt is installed?

Thank you.

[Steven E. Protter]

Shalom,

I believe login time is kept even without the SecurityExt.

After installation of the bundle any accounts not used the past 45 days may be locked instantly.

SEP