From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: ssh-host-config: patch fix debug option + broken for me on Vista (non-domain)
Date: Mon, 23 Jan 2017 10:19:00 -0000 [thread overview]
Message-ID: <20170123101904.GA3385@calimero.vinschen.de> (raw)
In-Reply-To: <252a5384-0979-7912-18ca-b8ceeccdb016@shaddybaddah.name>
[-- Attachment #1: Type: text/plain, Size: 4131 bytes --]
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 == 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.
>
> Thank you szgyg. This is on the right track. There is a variation. I
> didn't use the RunAs command.
>
> 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.
>
> 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.
>
> 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...
>
> 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".
>
> 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,,*}" != "${LOGONSERVER,,*}" ]
then
# Lowercase of USERDOMAIN
csih_PRIVILEGED_USERNAME="${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
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2017-01-23 10:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-18 3:34 Shaddy Baddah
2017-01-18 3:38 ` Shaddy Baddah
2017-01-19 10:38 ` Corinna Vinschen
2017-01-19 11:26 ` Shaddy Baddah
2017-01-19 18:16 ` Corinna Vinschen
2017-01-20 22:40 ` szgyg
2017-01-23 3:13 ` Shaddy Baddah
2017-01-23 10:19 ` Corinna Vinschen [this message]
2017-01-23 19:50 ` Achim Gratz
2017-01-23 20:19 ` Wells, Roger K.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170123101904.GA3385@calimero.vinschen.de \
--to=corinna-cygwin@cygwin.com \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).