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=G//0aICDavnXdqodfbhJTuYBP0gJrBCW86B8gPU/ubJCe+lIKAZCv
	mWVPLILaYBcXshyI4M2RkJ2Jj56l05klFI35+C4x3k/CHWbEDSfZYgQN/VZ0DhwK
	RzKz6dU3M/PNfDW2xKzvJbTr1PY5Tlk/0qtMjgCXsBohHkogiLoYfk=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Mon, 23 Jan 2017 11:19:04 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: ssh-host-config: patch fix debug option + broken for me on Vista (non-domain)
Message-ID: <20170123101904.GA3385@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <20170119181643 DOT GB25162 AT calimero DOT vinschen DOT de> <252a5384-0979-7912-18ca-b8ceeccdb016 AT shaddybaddah DOT name>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e"
Content-Disposition: inline
In-Reply-To: <252a5384-0979-7912-18ca-b8ceeccdb016@shaddybaddah.name>
User-Agent: Mutt/1.7.1 (2016-10-04)

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

On Jan 23 14:12, Shaddy Baddah wrote:
> On 21/01/17 09:40, szgyg wrote:
> > On 1/19/2017 7:16 PM, Corinna Vinschen wrote:
> >> The idea is that if LOGONSERVER =3D=3D COMPUTERNAME your
> >> machine is not in a domain.  Actually, I *never* encountered an
> >> environment
> >> in which LOGONSERVER isn't set.
> >
> > It's empty if you're using RunAs.
>=20
> Thank you szgyg. This is on the right track. There is a variation. I
> didn't use the RunAs command.
>=20
> Instead I did what I think is the almost 100% use case for running
> ssh-host-config. Which is to launch mintty by select "Run as
> administrator", elevate privilege to allow the script to add users and
> services, etc.
>=20
> The difference is as follows. And I test for this. I login to the
> desktop as a non-administrator. When I select "Run as administrator" I
> am prompted to enter a password for (one of) the administrator users.
>=20
> That mintty (and cmd prompt too obviously) do not have LOGONSERVER set.

Yes, you're both right, but it's even more weird.  If I use "RunAs" from
an unprivileged user account, and the Admin account I "RunAs" as is
logged on in another terminal session at the same time, the "RunAs"
session has LOGONSERVER set.  Something isn't quite right in the
backgrounds...

> Also, there is another use case which I haven't tried, but I would feel
> would result in no LOGONSERVER as well... not sure. I can try it as I
> complete this email...
>=20
> That is logging in to an administrator user via ssh itself.

No, that works as desired with LOGONSERVER set.

> As an aside... doesn't seem like the administrator user has the elevated
> privileges anymore. It was the case in the past. I never picked up on
> that change.

I don't understand what you mean here.  The privileges are not in the
user token of the non-privileged processes in a non-elevated session,
but as soon as you use "runas", the privileges are in the user token.

> To that end, please find attached the patch to fix the LOGONSERVER
> problem. I think it should be fine for a domain environment. Because if
> you run as a domain assigned local administrator, LOGONSERVER will be
> set, even on a "Run as administrator".
>=20
> If you just run as a local computer administrator (whatever the
> accurate terminology is here), then you will have an empty LOGONSERVER
> and the script will run for the local user.

No, that's not right.  If you run a logon session as a local admin (in
contrast to running a process via "RunAs"), LOGONSERVER will be set
to \\$COMPUTERNAME.

I'm also not quite sure if the patch is right.  The comment preceeding
the check explains what we want.  The idea is this (omitting the
extra test for "MicrosoftAccount"):

   # This test succeeds on domain member machines only, not on DCs.
    if [ "\\\\${COMPUTERNAME,,*}" !=3D "${LOGONSERVER,,*}" ]
    then
      # Lowercase of USERDOMAIN
      csih_PRIVILEGED_USERNAME=3D"${COMPUTERNAME,,*}+${username}"
    fi

COMPUTERNAME is the same as LOGONSERVER on non-domain machines as well
as on domain controllers.  So this `if' test if the machine is a domain
member machine.

If it is, local accounts will have the Cygwin username
"$COMPUTERNAME+$username", while on non-domain machines and DCs the
Cygwin username of a local user will be "$username" only,

This is according to the rules of automatic username generation per
https://cygwin.com/cygwin-ug-net/ntsec.html,

What your patch does is to handle an empty LOGONSERVER as an indicator
that we're on a domain member machine.  This doesn't look right to me.

So the basic question is this:  Assuming I'm running a simple bash
script, and assuming I can't rely on the value of LOGONSERVER for the
test on being a domain member machine, how *can* I check for that?
nltest, somehow?  But as far as I can see, nltest was only bundeled
with Windows 7 and later...  Do we have to write another helper tool?


Corinna

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

--cNdxnHkX5QqsyA0e
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJYhdiYAAoJEPU2Bp2uRE+gfREP/2gpijsAgIIaQzv++bIrVBdJ
xHX8m/zoekx2T4FJb6/bm3ZygErt1ktNdSGGs5nEQmQIpv7Yf5lV49AtFmgA7dUH
Rop2dnmozJuqba4X3zCcXWsakKVWACDZsZasqvX/2fbbcF8N+moOkY62Vo3gnVAd
U6IeeletZRMmb8BIgp5GcS6OReKo5kGnYsNeSfkjFQu3LKnCElib7V2KbpihSYnx
7wvFDmyk/RjJb/XAtSRHXB8W6IJC8LpTAokcqc4Y2uR5Ij+sVoOKFQGV8o5e83vV
K3GMJW0ekSqkp7uESxPoSUmsVz0+4fGIC8plqZOalQ3HJ4Y34uvSjehfgP4Svh6a
n4sLY58j2kAzzVpunw+8HqplohEhKB2aiXxiPlszN47eVTLN0nC5v5BzMJc1OqnK
EOebmLAGj6ZbvBatzpVsXZBKW9Dik3h9jP9ZKYU6Wfi20ww8dWDaMSwc42a4i/fO
XE+FJxx81TjWnLvbxadK2sSdBwVpVlCLZ+Q67bEpL1XsDRTb7leOzxs5rhCt+G65
VyswMgbMQQau/5p84bJm3pqgQU0sxJ8/O8GbSBZXyPv8rBSFyxbWzYfWC+i3L7y7
5JZFklT0FzESNv+8/zL9i4SxHS+Kyoe+pJ37dAY79d/QLR1DNRg+MRH/T+QcPaVw
tGsSndyAN0PBXRPgPpaL
=wnmd
-----END PGP SIGNATURE-----

--cNdxnHkX5QqsyA0e--