On Thu, Mar 27, 2025 at 12:14:39PM +0100, Ingo Schwarze wrote: > I think the proper order of actions is: > > 1. stsp@ deciding on the recommendation > and documenting and testing it. > 2. Either of us drafting a patch to security > and all three of us testing it. > 3. stsp@ committing the got(1) patch(es), either of us committing > the security(8) patch. > 4. stsp@ making a got(1) release and updating the port. > 5. You running the updated port in production. > > Thoughts?
I don't see a need for such strong conventions. The security script just issues warnings after the fact. If a mistake is made during setup, such that unauthorized shell access is possible without a password, then by the time the security script gets to run and sends mail and the admin gets to read it and starts to act upon it, it is already too late to do anything about the problem. The system should be assumed compromised and will need to be decommissioned. So why can the username and shell not be a simple configurable knob, like SKIPSUID already is, to suppress this warning for a specific account the admin is already very much aware of? As it is right now, with no way to disable this report short of editing the script, I just keep deleting all daily security mail from my gotd servers unread, assuming I know what it is warning me about yet again.
