Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 3 Dec 2013 14:34:07 -0500
From: Rich Felker <>
Subject: Re: _PATH_LASTLOG

On Tue, Dec 03, 2013 at 05:44:04PM +0000, Raphael Cohn wrote:
> Hi,
> I'm trying to compile linux-pam 1.1.8 using musl-cross, and I've hit a
> compilation error in  modules/pam_lastlog/pam_lastlog.c
> Essentially, this code includes the clib utmp.h (based on HAVE_UTMP_H) and
> then assumes _PATH_LASTLOG is defined.

This is a bug in pam. It should be testing #ifdef _PATH_LASTLOG.
_PATH_LASTLOG is not specified to be defined anywhere, much less
utmp.h; its presence is a glibc "feature". At present musl has some of
these paths that are fairly universally-agreed-upon in paths.h, but
it's really bad design for libc to be imposing policy for things that
have nothing to do with libc itself through the headers it installs.
(In fact, if I'm not mistaken, most distros patch glibc's paths.h to
conform to their FS layours...)

> utmp.h doesn't define this macro, but does define _PATH_UTMP and
> _PATH_WTMP. Should it? (And why are they set to /dev/null/xxx )?

These are all very good questions. At present musl does not support
storing anything to utmp, and uses /dev/null/xxx as a pathname that
will fail to open and fail to unlink (since /dev/null is required by
POSIX to exist as a device, i.e. not a directory). (Using /dev/null
would be dangerous since some broken programs unlink the utmp file and
make a new one.)


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.