On Sun, Jul 14, 2024 at 7:22 AM Chris Hofstaedtler <z...@debian.org> wrote: > > On Sat, Jul 13, 2024 at 11:33:01PM -0400, ov2k wrote: > > wtmpdb respects the system-wide umask when creating > > /var/lib/wtmpdb/wtmp.db. This is inappropriate when the system-wide > > umask is 077 or something similarly restrictive, as wtmp.db can no > > longer be read by others > > That however might be the intention of a local configuration. IOW > admins might want to set it up so that login records are not leaked > to non-root. > > > (e.g., GNU screen). > > I'm not sure why GNU screen reads wtmp.db? Could you expand on that?
That's a mistake on my part. It's a call to last in a startup script of a non-privileged user. > > > The problem occurs if the > > system-wide umask is configured during installation (before wtmp.db is > > created) or if wtmp.db is removed at any point after the system-wide > > umask has been configured. > > Just to be clear, how did you set up the system-wide umask? via /etc/default/login. I think that's how it's managed now with pam_umask.so. I do this before exiting the installer. > > > One solution would be to create wtmp.db as part of the wtmpdb package > > postinst. From my testing, I think just touching an empty file with the > > proper permissions would suffice. > > This is probably not sufficient after rotation of the database. Good point. Can rotation preserve existing permissions? If an administrator with the default umask 022 were to change permissions on the database, would they get lost after rotation? > > > Another solution would be for wtmpdb to explicitly set the mode of > > wtmp.db to 644 every time the database file is created. I'm not sure > > whether it should occur if wtmp.db is an existing empty file. > > I think this will make hiding login records from non-root > impossible, thus also not desirable. > > > Additional clarification: above you said: > > wtmpdb respects the system-wide umask when creating > > /var/lib/wtmpdb/wtmp.db. > > However wtmpdb does not create that file; instead libpam-wtmpdb > does. Could you clarify more what exactly you configured, and which > behaviour you observed on which events/commands? > > Chris > Sorry, I'm not that familiar with the various wtmpdb packages. To summarize, I set UMASK=077 in /etc/default/login in the installer. After rebooting and logging in, last called as an unprivileged user reported not being able to access wtmp.db because its mode was 600 instead of the 664 wtmp gets. I don't normally touch the permissions with wtmp, even with umask 077, and I expected the same of libpam-wtmpdb. From what you were saying earlier, it sounds like any customizations made to the wtmp.db permissions would get lost on rotation, and reset to whatever results after the system-wide umask is applied.
