An overview of utmps

utmps is a secure implementation of the utmp functionality, i.e. user accounting on Unix systems. It includes full POSIX utmpx.h functionality, a few extensions created by GNU, and an underlying C client library with better error reporting than the POSIX interface specifies.

The issues with traditional utmp

Traditional utmp implementations, as performed by most Unix libcs, are woefully insecure. The fundamental issue with utmp is that it requires user programs to write to files (the utmp or wtmp databases) owned by either root or a specific system user. That means having the suid bit set on programs using it.

The utmps solution

utmps uses the age old Unix client-server model, following the adage "one resource → one daemon". It provides two daemons, utmps-utmpd and utmps-wtmpd, which should be the only programs allowed to access the utmp and wtmp databases respectively. It provides the utmps client library to communicate with those daemons; and it implements the utmpx.h interfaces, and the extensions, as wrappers for this client library.

Authentication, local services and superservers

utmps-utmpd and utmps-wtmpd do not listen to the network themselves. They are designed to serve only one client connection, following the UCSPI model - also known as the inetd model. To implement the utmpd and wtmpd local services, a Unix domain superserver such as s6-ipcserver is required. s6-ipcserver listens to a socket, and spawns a utmps-utmpd process when a client calls setutxent() for instance.

The utmpd and wtmpd services must be started at boot time in order for utmp calls to succeed. The examples/ subdirectory of the utmps package has examples on how to start those services when using the s6 supervision suite, the s6-rc service manager, or the OpenRC service manager.

This model has advantages and drawbacks. The main drawback is that it requires a daemon to be running in order for the system to provide full POSIX functionality. The main advantage, on the other hand, is that no program needs to be suid or sgid, and permissions can actually be quite fine-grained.

utmps-utmpd will allow any user to read from the utmp database, but will only allow root to write to it.
utmps-wtmpd will only allow a user to add an entry to the wtmp database if the user is root, or if the ut_user field of the added entry resolves to the user's effective uid.
The s6-ipcserver superserver, which is recommended to implement the utmpd and wtmpd services, allows fine-tuning the permissions: it is possible to deny users from connecting to the service, or to only allow certain groups, etc.

All in all, I believe the flexibility it offers overweighs the inconvenience of having to run services before providing utmp/wtmp.