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: List-Subscribe: List-Archive: List-Post: List-Help: , 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" To: cygwin AT cygwin DOT com User-Agent: SquirrelMail/1.4.18 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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