> 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
