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? > 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? > 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. > 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
