[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#645788: openssh-server: /run on tmpfs breaks sshd started from inetd



Am 24.02.2012 09:55, schrieb Colin Watson:
On Tue, Oct 18, 2011 at 06:56:07PM +0200, Dirk Heinrichs wrote:
I'm running sshd with priviledge separation enabled from inetd, but
since some time I can't login anymore after reboot.

In /var/log/auth.log, I see the followin message:

fatal: Missing privilege separation directory: /var/run/sshd

The reason for this is that /var/run is now a symlink to /run, which
is mounted as a tmpfs, thus it doesn't survive a reboot.

I'm not sure what I can do about this.  The init script ensures that
/var/run/sshd exists; isn't it your responsibility to make suitable
arrangements when locally configuring sshd to start from inetd?

Well, that's what I did, of course. I've put this into /etc/rc.local:

[[ -d /run/sshd ]] || mkdir -p /run/sshd

(I suppose you could argue that the Debian packaging should set the
privsep path to /var/lib/sshd instead.  That seems quite difficult to
change now though ...)

Hmm, why has it been changed from the default (/var/empty) in the first place?

If the package would simply do what README.privsep says, everything would be fine, no matter how sshd is finally invoked. From README.privsep:

"You should do something like the following to prepare the privsep
preauth environment:

	# mkdir /var/empty
	# chown root:sys /var/empty
	# chmod 755 /var/empty
	# groupadd sshd
	# useradd -g sshd -c 'sshd privsep' -d /var/empty -s /bin/false sshd

/var/empty should not contain any files.

configure supports the following options to change the default
privsep user and chroot directory:

  --with-privsep-path=xxx Path for privilege separation chroot
--with-privsep-user=user Specify non-privileged user for privilege separation"

Bye...

	Dirk



Reply to: