Deleting and re-creating utmp/wtmp - maybe stop doing so?

[gerard@…]

From Archaic:

According to the manpage:

Warning: utmp must not be writable, because many system programs (foolishly) depend on its integrity. You risk faked system logfiles and modifications of system files if you leave utmp writable to any user.

But then:

BUGS: This manpage is based on the libc5 one, things may work differently now.

Then from info utmp:

The user accounting database typically lives in `/etc/utmp', /var/adm/utmp' or /var/run/utmp'. However, these files should *never* be accessed directly. For reading information from and writing information to the user accounting database, the functions described in this section should be used.

Which brings me to /etc/rc.d/init.d/cleanfs:

echo "Creating new /var/run/utmp..." touch /var/run/utmp && chmod 644 /var/run/utmp evaluate_retval

Should we perhaps change it, or is this sufficient? Also, what about deleting and re-creating wtmp? It's all still a little fuzzy with that one.

[gerard@…]

The message that spawned this bug was posted today, so there's no archive link yet. When somebody gets around it, add the link to archive. Subject of the originating email was: "utmp and wtmp" on April 29, 2003

[jeremy@…]

Added link to the archive post for this one.

[greg@…]

I've looked into this. The libc info docs are are referring to *programs* when they say the files should never be accessed directly. The fact that our bootscripts touch the file is a different thing and not a problem. There was some discussion on the glibc list recently and there are indeed some programs that do want to touch the files directly instead of using the libc functions, but that is not the problem this bug report is addressing. Additionally, the 644 permissions seem ok because users don't have direct write access.

wtmp is supposed to be persistent AFAICT.

In summary, I don't think there is any problem here at all.