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:message-id:in-reply-to:references:date:subject
	:from:to:mime-version:content-type:content-transfer-encoding; q=
	dns; s=default; b=kYe9fsL/+ZDzeH+VEnlBfu/4E/2Jzj5n7iGl0yK97TBRa3
	irOhL1BpXg4P+xlFl9ZzO4fhAiaLe39ef0hJy+RBxTOLaD6HWNdMbQrm9y2WyANU
	iahApegmBVBzxMQRzdPP3b9ds5rCKUTJqpqHyclp6aj/vgpN7U5urbmU/9Xgc=
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:message-id:in-reply-to:references:date:subject
	:from:to:mime-version:content-type:content-transfer-encoding; s=
	default; bh=kWbUwra9K4cTV8G3hlIq5Ksnphw=; b=w5OzU3ept+F/Rf1Ikc9C
	zp4aYsuI55fOnDJ442II+PrFiveXsBKFZifSfHVpLuO0rEidfj606QEq5thBy5x9
	ZeDDdEc6OPUcRXXyXjHeqorC+4lYeq/OL5GNRmGh01Ugs4HFqRZun4E2VVGEfzsr
	OUo8N9lqIQqcFH/uCPT3mA4=
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=-0.2 required=5.0 tests=AWL,BAYES_05,NORMAL_HTTP_TO_IP,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD autolearn=ham version=3.3.2
X-HELO:	smtp-vbr6.xs4all.nl
Message-ID:	<6f9d939cc604437def11828435a67f96.squirrel@webmail.xs4all.nl>
In-Reply-To:	<536E339A.6030200@breisch.org>
References:	<849f1f5420ebf77d7a591d6c9b6bfa4b DOT squirrel AT webmail DOT xs4all DOT nl> <536E339A DOT 6030200 AT breisch DOT org>
Date:	Mon, 12 May 2014 14:20:13 +0200
Subject:	Re: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?
From:	"Houder" <houder AT xs4all DOT nl>
To:	cygwin AT cygwin DOT com
User-Agent:	SquirrelMail/1.4.18
MIME-Version:	1.0
X-IsSubscribed:	yes

> At my place I have installed both versions of Cygwin (i.e. 32-bits and 64-bits) -- of course,
> in different places.  As "some" of you will have the "same" setup, I would like you to confirm
> the following (UNexpected, to me) result:
>
>  - I canNOT invoke regedit from 64-bits bash (Yes, I can if bash has been invoked in ELEVATED mode)
>  - I can invoke regedit from 64-bits bash (not elevated) as follows: cygstart regedit
>  - however, I can invoke regedit from 32-bits bash (not elevated) ...
>  - likewise, I can invoke regedit from 64-bits cmd (not elevated) ...
>
> By UNexpected result I mean: I cannot explain why I canNOT invoke regedit from 64-bits bash ...
>
> My installation in general:
>
>  - stand-alone installation (i.e. not connected to a domain)
>  - standard passwd and group files
>  - nsswitch.conf: passwd: file, group: files, db_enum: files

Hi Chris,

Thanks for the input!

Of course, it is not really a problem, that regedit cannot be invoked from Cygwin, as it can
be invoked from the Windows interface ...

However, in some of the "harder" cases of using Gygwin, one needs to have a "mental" model of
how Cygwin "integrates" with Windows (is my belief) ... and as far I understand the matter, I
was surprised to find that I could not invoke regedit from bash.

Consequently, I decided to investigate why I got the denial (64-bits Cygwin) at my end.

First of all, some more info about my "environment":

 - I am using Cygwin from Windows 7 ...
 - I am using Cygwin from an administrative account ...
 - furthermore, using secpol.msc, I have set the ConsentPromptBehaviorAdmin field in

   HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System (key in registry)

   to zero, meaning 'elevate without prompting'
   (default: 5, meaning 'prompt for consent for non-Windows binaries)

Note: secpol.msc: security settings > local policies > security options > User Account Control: \
Behavior of the elevation prompt for administrators in Admin Approval Mode

As result of doing that, I am still able to "elevate" using a Standard User Account (as far as I
can remember), while am I able to "elevate" using the Administrative Account without being asked
for consent ...

Back to the issue I started with (back to my investigation).

Using the event viewer (Windows), I have been able to "connect" the denial, reported by 64-bits
bash, with error 'ERROR_ELEVATION_REQUIRED'.

Note: event viewer: applications and services logs > microsoft > windows > uac > operational

Each time I got the denial, an entry was being added to this particular log.

Searching the internet, it got the understanding, that this (new) error value is not handled as it
should be handled ... as far as I understand, the user should be (normally) be asked for consent.

Not handled correctly where? 64-bits bash? 64-bits Cygwin? I cannot tell.

Strangely enough, all of the following invocations of regedit were succesful at my place:

64-@@ cmd /c 'c:\Windows\regedit'
64-@@ cygstart /drv/c/Windows/regedit
64-@@ /drv/e/Cygwin/bin/bash -c /drv/c/Windows/regedit

Note:
 - in all of the above cases, 64-bits regedit is being invoked
 - specifying /drv/c/Windows/SysWOW64/regedit invokes 32-bits regedit (successful)
 - and, as I reported before, regedit can be invoked as "usual" from 64-bits bash if bash has been
   "elevated"

Btw, using a Standard User Account, regedit can be invoked from 64-bits bash as "usual" ...

As you will notice, invocation of regedit using cygstart (from 64-bit bash) does NOT fail. As far
as I know, cygstart makes use of the "ShellExecute" API i.s.o. the "CreateProcess ?????" API ...
Searching the internet again, it was suggested to me, that the "ShellExecute" API, different from
the other API I mentioned above, takes "appropriate" action in case of ERROR_ELEVATION_REQUIRED.

Another issue you might run into ...

I was surprised to find, that 32-bits bash reported /drv/c/Windows/regedit.exe as a different file,
compared to what 64-bits bash reported.

Note: 32-bits cmd and 64-bits cmd report c:/Windows/regedit.exe as the SAME file. Which, of course,
made me wonder ...

Searching the internet again, I got the understanding, that there has been been a time in which a
request for c:/Windows/regedit.exe was redirected to c:/Windows/SysWOW64/regedit.exe (in case of a
32-bits application).

As far as I can tell, this redirection no longer applies (meaning, as far as can tell, MS changed
its mind here).

My findings and questions in a nutshell:

 - by "default" 64-bits regedit is succesfully invoked from 64-bits cmd, and 32-bits regedit from
   32-bits cmd.
 - both 32-bits cmd and 64-bits cmd list the 64-bits regedit in c:/Windows

 - ... basically, "by default" the same should happen if regedit is invoked from bash ...
    - why does "64-bits Cygwin" (bash?) fail on the invocation of regedit?
 - 32-bits Cygwin (using bash) shows a "32-bits" regedit in /drv/c/Windows
    - does "32-bits Cygwin" (bash?) use a "deprecated API" that still redirects c:/Windows/regedit
      to c:/Windows/SysWOW64/regedit?

It should be obvious, Chris, that I canNOT say why you cannot invoke regedit from 32-bits Cygwin at
your place, as I cannot tell you WHAT to look for.

My hope, when I sent my original message, was, that more than one person would reply. It would have
enabled me "to compare notes".

Thanks all for reading this far ;-),

Henri

@@ bash --version | grep bash
GNU bash, version 4.1.10(4)-release (i686-pc-cygwin)

64-@@ bash --version | grep bash
GNU bash, version 4.1.11(2)-release (x86_64-unknown-cygwin)

=====


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -