[Pkg-shadow-devel] Bug#922945: Bug#922945: /var/log/lastlog is a 110 TByte sparse file, seriously affecting backup

[Sam Morris]

On Fri, Apr 16, 2021 at 01:30:36PM +0200, Bálint Réczey wrote:
> Control: severity -1 wishlist
> Control: tags -1 confirmed upstream
> 
> Hi Sam,
> 
> Sam Morris <sam at robots.org.uk> ezt írta (időpont: 2021. ápr. 13., K, 19:45):
> >
> > On Tue, 2021-04-13 at 15:26 +0200, Chris Hofstaedtler wrote:
> > > This will then silently hide login failures from userids larger than
> > > this ID? Given the original submitter has a user with uid 379400000,
> > > why whould this not be logged?
> > >
> > > If they didn't want those uids to be used, maybe dont assign them?
> > >
> > > Chris
> >
> > I think login.defs(5) says it best:
> >
> > "As higher user IDs are usually tracked by remote user identity and
> > authentication services there is no need to create a huge sparse
> > lastlog file for them."
> >
> > The design of the lastlog format means you either have an apparantly
> > huge (sparse) file, which causes problems for badly written backup
> > software, or you don't record information for users with high UIDs in
> > this file at all.
> >
> > In any case, it looks like OpenSSH has its own code to read/write to
> > /var/log/lastlog, rather than using pam_lastlog, so in any case
> > changing login.defs wouldn't be sufficient.
> 
> Lastlog format is stable for a very long time and I don't think it
> would be wise to change it and as Chris pointed out shipping a default
> low LASTLOG_UID_MAX would hide login failures which is also not desired as
> a default.

Hold on, I think we're getting a little mixed up here...

/var/log/lastb is the file that tracks login failures. LASTLOG_UID_MAX
won't affects writes to that file (which in any case are done directly
by login(1), gdm3(8), sshd(8), etc., and not via PAM).

/var/log/lastlog tracks the last successful login. Interestingly, in
Debian's default configuration, in practice this only means the last
login with a tty. This is because pam_lastlog(8) is only included in
/etc/pam.d/login, rather than /etc/pam.d/common-session. Other programs
that log users in to the system are expected to update /var/log/lastlog
(and /var/log/wtmp and /run/utmp) themselves... and in the case of
sshd(8), it only does so when it alloacates a tty!

So in practice, 'ssh host mycommand' bypasses the logging into
/var/log/wtmp and /var/log/lastlog entirely. And logins via gdm(3)
aren't recorded in /var/log/lastlog at all. Maybe this is just common
knowledge, but I am a bit surprised by this!

Anyway, I don't have much more to add to this bug. Before I added my
comments, I was under the impression that the handling of the
lastlog/lastb/wtmp/utmp files was performed by PAM, giving consistent
behaviour between applications; but sadly this is not the case.

To summarize, the large apparant size of /var/log/lastlog is not a bug;
backup software should be able to deal with sparse files; there is no
central configuration to control writes to /var/log/lastlog; so this bug
may as well be tagged wontfix.

-- 
Sam Morris <https://robots.org.uk/>
CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9