Or to see which user caused the security notice that /etc/spwd.db was changed?

  • 1
    The passwd struct defined in pwd.h has a time_t pw_change field. However, writing a naive C program to read the password database using getpwent(3) only returns zeros... I wonder if there was a decision taken at some point to not use that field?
    – Kusalananda
    Mar 27 at 21:48
  • Thanks for checking that @Kusalananda ... I'd wonder the same thing. While I appreciate that privacy is an important part of security I find the lack of auditability here inappropriate.
    – tink
    Mar 27 at 21:54
  • Well, it's simple to set up process accounting (see /etc/rc.conf) and then use lastcomm to figure out exactly who used passwd and when (as long as they do it while process accounting is activated). The fact that you have not enabled process accounting is no fault of the OpenBSD devs. My initial comment was only referring to trying to use the actual password database itself to get at the info.
    – Kusalananda
    Mar 27 at 22:01
  • 1
    I'll let this simmer for now to see whether somebody picks it up and writes a proper answer. If nobody does, I might come back to it later. I'm not the expert, and I'd rather that e.g. @aviro wrote something (they have obviously worked with OpenBSD accounting before) than me, who would need to do a lot of testing to get things right.
    – Kusalananda
    Mar 27 at 22:35
  • 1
    @tink FYI, process accounting, though originated from BSD, exists in Linux for a very long time and is even more advanced, since it keeps additional details of each process such as the exit code and the ppid. Unfortunately the tools that display it (lastcomm and on the GNU implementation also dump-acct) are difficult to parse and to understand, so it's a pretty obscure and underutilized feature. One day I'll release my tool that analyzes the pacct file and change the world. ;)
    – aviro
    Mar 28 at 16:14

2 Answers 2


On OpenBSD, you need to start process accounting wuth the accton command:

touch /var/account/acct   # The file has to exist before accton
accton /var/account/acct

To have accton enabled at boot time, use:

rcctl enable accounting

which sets accounting=YES in /etc/rc.conf.local.

Anyway, now that you have process accounting enabled, you can use lastcomm to view the list of executed commands, and search for processes named passwd and pwd_mkdb. The output will be shown in reverse, where latest processes are displayed first (according to their termination time, not the time they started):

$ lastcomm passwd pwd_mkdb
passwd[18349]                         -       root                             ttyC1      0.28 secs Thu Mar 28 11:02 (0:00:17.39)
pwd_mkdb[27720]                       -       root                             ttyC1      0.00 secs Thu Mar 28 11:02 (0:00:00.00)
passwd[58119]                         -F      aviro                            ttyC1      0.00 secs Thu Mar 28 11:02 (0:00:00.00)
passwd[1586]                          -       root                             ttyC0      0.22 secs Thu Mar 28 10:11 (0:00:10.02)
pwd_mkdb[27986]                       -       root                             ttyC0      0.00 secs Thu Mar 28 10:11 (0:00:00.00)
passwd[64663]                         -F      aviro                            ttyC0      0.00 secs Thu Mar 28 10:11 (0:00:00.00)

Every successful password change will show in the history at least three processes (more or less at the same time, and also at the same tty:

  1. passwd process owned by root. This command has to be run with elevated privileges, so the exexutable file has the setuid bit set, thus it has root's effective uid.
  2. pwd_mkdb command also owned by root. It's self explanatory.
  3. And another passwd, this time under user that changed the password as the owner. This is a process that's forked from the original passwd command to check if the password is strong enough, and drops privileges back to the real uid. This is fortunate, because if it weren't for this low privileged child with under the original uid, you had no way to know who ran the command. This process might appear more than one time, if the user provided a password that didn't adhere to the requirements and had to provide a different password.
  • Just to say that I believe the two first commands are automatically executed by the system's rc scripts if the system is booted with accounting=YES in /etc/rc.conf.local.
    – Kusalananda
    Mar 28 at 16:21
  • @Kusalananda right, and I mentioned it also in my answer. But if you want to start accounting without rebooting the system, you'll have to run them manually.
    – aviro
    Mar 28 at 16:26
  • Thank you @aviro - the output is a bit more garrulous and uglier than I hoped for, but it will have to do :) ... I'll ask my colleagues what they think about making accounting happen in our environment. Do you have an estimate regarding the growth rate of accounting data on a system that doesn't see too many interactive logins? The machines in question only serve as vpn servers and receive some love when they let us know that syspatches are available.
    – tink
    Mar 28 at 18:30
  • @aviro Sorry, I misread that part. I read it as if you said setting accounting=YES was optional, which it wouldn't be unless you only wanted to turn it on manually and temporarily.
    – Kusalananda
    Mar 28 at 21:42
  • 1
    @tink On my personal system, it's a matter of about 500 KB of data per day, which is rotated on a daily basis and kept for four days.
    – Kusalananda
    Mar 28 at 21:45

And I have discovered a more light-weight method of seeing who changed the password (even though it doesn't tie it to a specific time-stamp, and would leave me wondering if two or more people were to change passwords on the same day), but given that password changes or addition or deletion of users on those machines happens at best once a year I can live with the risk).

Looking at the time-stamp and checking

diff /var/backups/master.passwd.*

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .