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 <s...@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