deprecation of UsePrivilegeSeparation breaks container use cases

Darren Tucker dtucker at
Mon Aug 7 10:17:09 AEST 2017

On Mon, Aug 7, 2017 at 5:44 AM, Aleksandar Kostadinov <akostadinov at
> wrote:

> Hello,
> there are emerging container services that restrict regular users to
> launch containers under some random uid for security reasons. If such
> user needs sshd in their container, they need to turn off
> `UsePrivilegeSeparation` so that sshd is executed as the current uid
> and not `root`.

That's not accurate.  As of 7.5p1 it required that the privsep user and dir
exist but as long as they do it'll work as an unprivileged user.  As of
this commit:
it won't require the user or dir.

As I said last time this came up:
Disabling privsep will not be supported.  Running as an unprivileged user
is supported in the two-process configuration.

I understand that privilege separation [1] is more than changing the
> process uid. On the other hand, it is unreasonable to expect
> administrators to let regular users execute privileged code of any
> sort. If they do so, this would compromise security of all other
> users.
> And I can't see how privilege separation can work without giving
> regular users elevated privileges of some sort. Especially giving
> users `chroot` privileges would be highly dangerous.

It's not just chroot.  There are some protections that work even
unprivileged (eg OpenBSD's pledge or the admittedly weak rlimit sandbox)
and removal of the !privsep code paths will reduce complexity (both code
and configurations).


> Do you have other ideas how container use cases can be covered in the
> future without giving the users dangerous privileges?

See above.

Darren Tucker (dtucker at
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

More information about the openssh-unix-dev mailing list