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
