It sounds like things got pretty complicated, but I think you’ve addressed my concerns. Thank you.
On Thu, Sep 25, 2025 at 3:37 AM Andrew Bower <[email protected]> wrote: > Hi ov2k, > > A note on the resolution of this bug: > > On Sun, Jul 14, 2024 at 11:42:54AM -0400, ov2k wrote: > > On Sun, Jul 14, 2024 at 7:22 AM Chris Hofstaedtler <[email protected]> > 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. > [...] > > > > 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? > > The rotation scheme provided by wtmpdb sufers from this problem: it does > not preserve the permissions of the old log. That rotation scheme was > defective in so many ways (#1094965) that it did more harm than good and > was > disabled by default in installations of the trixie release pending the > provision of a better solution (which proved elusive). > > Version 0.74.0-1 of wtmpdb, now in the experimental suite, uses > logrotate(8) for log rotation and pruning. Logrotate knows all about how > to do this properly and now both the rotated logs and live database file > retain the same permissions of the previous database file. > > This bug is therefore fixed as a side effect of the new rotation scheme. > > As for the initial file creation, I think it is sufficient for you to > set this up yourself by touching the file, just as you are seeding your > desired system-wide umask settings in the filesystem. > > Therefore I think we can now close this. > > > > > 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. > > Indeed. > > You might also consider adding a file to /etc/tmpfiles.d, if your system > uses tmpfiles.d, to handle creating a new database file with your > preferred properties in case it goes missing for any reason as you > suggested it might above. > > I hope this does what you need now. > > Andrew >
