On Tue, Mar 28, 2017 at 2:23 AM, Jack Dodds <brmdamon@xxxxxxxxxxxx> wrote: > Hello Darren, > > Could you comment on this issue being raised by myself and > Corinna Vinschen? > > This will create big problems for me. > > I'm not clear if this is a conscious decision supported by solid > reasons or if it is just collateral damage. > > Thank you for all you work! > > Jack DoDDs > > -------- Original Message -------- > Date: Mon, 27 Mar 2017 16:31:03 +0200 > Subject: Re: Announce: OpenSSH 7.5 released > From: Corinna Vinschen <vinschen@xxxxxxxxxx> > To: openssh-unix-dev@xxxxxxxxxxx > > On Mar 24 12:38, Jack Dodds wrote: > > Hello, > > > > You seem to be saying that in 7.5, sshd can no longer be run > > under an ordinary user account. Is that accurate? > > Well, yes, that's what the report claims, and it seems correct to > me. > It's not quite accurate. The issue is that it checks for the existence of the privsep user and directory even though it does not use them. If they exist (even if only because you configure'ed --with-privsep-user and --with-privsep-dir to point to other existing ones) then it'll work. This is what we use for the regression tests when SUDO is not set (but because all our test systems have the user and dir, we never observed the problem). > > I use sshd running under a user account in Debian Jessie to allow > > tunnels from remote devices. That capability is crucial to my > > application. > > > > Any comments would be appreciated. > > Same here. > > Is it really just a bug or is the "non-priv'ed user running sshd" > scenario going to be unsupported in future? > My opinion: - running as a non-privileged user should be supported. - running with privsep disabled (ie one unprivileged process) will not be supported. This will mean that you'll have two sshd processes per connection running as an unprivileged user, same as you would for a privileged user. Rationale: we want to reduce the code complexity by removing the !privsep code paths, and some privilege dropping mechanisms like OpenSBD's pledge can still be employed by unprivileged code). I've just committed a variation on the patch to both HEAD and the 7.5 branch. https://anongit.mindrot.org/openssh.git/commit/?id=d13281f2964abc5f2e535e1613c77fc61b0c53e7 -- Darren Tucker (dtucker at zip.com.au) 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. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
