X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=qu1mLtkzuueX4MaJH7qDxGGkzDVkdbT+XeoXDlMqgiB47xLkiziBR
	rHxAiE5nz7fLdvB9XUQgLWSkSKDtaOlKPUjwb62Se9eXaiGWVzF51sX/CXuk+Gcm
	1wBPaWvmp7sWfnQZzxFJxb8zKxP101RhGwoAtubZNSDLDzCm25BydY=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=bZXhPNSwzuCbdRN0O5OpxiqQ2i4=; b=GnBIM+zqHl10ctrzzL50lYcnz2LE
	erquk1O+nHyershvQdbwDyP8ZTq3cDuPgeLpCN/zpBBzfgYJ5wv/dcYPaFHo3DWG
	1J+HXvjegEorwR6hRlZwsNNOHQ7rc7qzBf8gR2kpqH01DvkdrWaWbxb7y4f+5GGE
	/jlAzmFaEGYXBOo=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-5.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2
X-HELO:	calimero.vinschen.de
Date:	Wed, 3 Sep 2014 15:26:16 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Windows Server 2012R2 64bit and 32bit Cygwin sshd
Message-ID:	<20140903132616.GK6056@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<8761hphfps DOT fsf AT Rainer DOT invalid> <loom DOT 20140902T134545-288 AT post DOT gmane DOT org> <20140902140751 DOT GD6056 AT calimero DOT vinschen DOT de> <loom DOT 20140902T171114-72 AT post DOT gmane DOT org> <20140902153757 DOT GE6056 AT calimero DOT vinschen DOT de> <loom DOT 20140903T084528-450 AT post DOT gmane DOT org>
MIME-Version:	1.0
In-Reply-To:	<loom.20140903T084528-450@post.gmane.org>
User-Agent:	Mutt/1.5.23 (2014-03-12)

--WuT04sMzYDXq8et0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sep  3 07:17, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > Don't use privilege separation, then the non-privileged sshd user won't
> > matter at all.  Privsep on Cygwin is only half-useful on Cygwin anyway,
> > if at all.
>=20
> I've switched privilege separateion off completely, but no dice.  The Acc=
ess
> Denied comes from trying to switch from primary group "MACHINE+None" to
> "Domain Users".  That is expected to happen, what I still don't get is why
> the parent process winds up with the exception instead of the originating
> process as on 64bit.

As I wrote, this is a red herring.  A failing setgid is no error at
all.  It has nothing to do with the exception, except for the debug
output preceeding the exception occurance.  Note the

  get_logon_server: DC: server: \\SC301

between them.  This, and the subsequent seterrno_from_win_error in the
parent sshd are a pretty sure sign that the exception is triggered by
the NetUserXXX calls.

> > As for the local cyg_server account, I'm not sure.  Usually,
> > a local machine account has no or only limited access to AD information.
> > As an account which needs AD to get user information it's a bit
> > unfortunate if it doesn't have access.
>=20
> When the process comes to this point it has already verified the user via=
 AD.

Yes, but this has nothing to do with it.  Before calling setuid (which
it calls a couple of times during login), sshd calls initgroups for the
new user, POSIX-like.  Initgroups in turn has to call NetUserGetGroups
and NetUserGetLocalGroups on the DC to fetch the full list of groups for
a user.  From the strace it *seems* that the call to NetUserGetGroups in
the grand child sshd process results in simply terminating the process.
The fact that there's no more output *at all* from the grand child
points to Windows killing the process hard.  Lacking any hint why this
occurs, it's just an assumption, of course.

> > The strace shows that it doesn't even *try* to start bash, but it's
> > entirely unclear why.
>=20
> Is it possible to run sshd in gdb?

Yes, but Windows/Cygwin gdb don't allow to follow the child process
so it's very tricky.


Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--WuT04sMzYDXq8et0
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUBxb3AAoJEPU2Bp2uRE+gNXwP/j0RtD2OKGQPPLwfEKy/jjco
rQWMQKfcwI/OBUVOwrproZGYPIecyCstHMDlGnP4EMO52jeaMORDh5rAhbaRMBbM
GtrY1sPVwI3UVD0zZY/HBexAdI7Umj7b7eMLjHYUi1r8MusV/8zwcYV4VStwNT6w
jMVuMxTCyAjyy9NUtzizcDXVUARKnBbIgQcJ5WJyzs/4ABiWkoZY1X2va/UItqoN
80jR84v/vw0sLqYp14cqhbU0pjcBH/VYDGSSk0ZuCAOX6ftLyxPRBpWbRoYE2o/+
btnHt7Zjgl0sEJLvylg7Q8SyoOOlp5xlcR2gfyCcBySsgEjrATNc0ze0iOZ9+Dxx
nvLgmms0LhkGXyvnJ8gGATQOIINqSR7MY0DB9AOFY6qfGEQueR5r8m5HujmI34S5
ESydkOolLsJhwpCBN6EI6Rm0v/KhrKeXflnXkqQy6LZxD3HLBMwlNOxrJZzXyDE4
BDR2R1DEBbrbPJq8lOyEavmsQA6TJihnmG3jDnkXc3sGJhMuvluyocmq/dtBTjRL
mk0StYBc1PAhnBEWuh27VbT7CfDIAq5ce525rfqrcfjTvqwhbKDUIXX0w/qTjbmm
jgS+zOaFkbwu/6xLDIiZutWcBfVXbr4uoI09UOosu/NoJFQqghF/Z9+IxVzX+XA/
KtOmaghOYzjY0AtDi1nh
=iadM
-----END PGP SIGNATURE-----

--WuT04sMzYDXq8et0--

- Raw text -