On Sun, Feb 17, 2019 at 09:48:03PM +0000, peter.ch...@data61.csiro.au wrote: > $ ls -l /run/sshd.pid > -rw-r--r-- 1 root staff 6 Feb 15 13:21 /run/sshd.pid > > I suspect the `staff' group is the issue. Got that way because I have > an su shortcut that puts me in uid 0 group 50 for /usr/local update, > and I must have restarted sshd with those credentials one time. > Should /etc/init.d/ssh set the credentials to create /run/ssh.pid with ?
Thanks; that was enough for me to reproduce this. This sort of thing is an intrinsic problem with sysvinit that's hard to fix generically: because init scripts are often invoked directly, it's common for details of the invoking user's environment to leak into the environment of the running process. I've added "--chuid 0:0" to the --start calls to force the correct group, and also added "--exec /usr/sbin/sshd" to the --stop calls which avoids this particular failure mode even if the ownership is currently wrong. Cheers, -- Colin Watson [cjwat...@debian.org]
