* Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?
@ 2014-05-10 13:42 Houder
2014-05-10 14:11 ` Chris J. Breisch
0 siblings, 1 reply; 11+ messages in thread
From: Houder @ 2014-05-10 13:42 UTC (permalink / raw)
To: cygwin
Hi,
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
---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
Using my 64-bits Cygwin installation (MinTTY, bash) at e:/Cygwin64:
64-@@ uname -a
CYGWIN_NT-6.1 Seven 1.7.30s(0.272/5/3) 20140426 17:41:38 x86_64 Cygwin
64-@@ echo $PATH
/usr/local/bin:/usr/bin:/drv/c/WINDOWS/system32:/drv/c/WINDOWS:/drv/c/WINDOWS/System32/Wbem:/home/Henri/bin
64-@@ pwd
/home/Henri
64-@@ which -a regedit
/drv/c/WINDOWS/regedit
64-@@ ls -l /drv/c/WINDOWS/regedit
-rwxrwx---+ 2 TrustedInstaller TrustedInstaller 427008 Jul 14 2009 /drv/c/WINDOWS/regedit
64-@@ stat /drv/c/WINDOWS/regedit
File: `/drv/c/WINDOWS/regedit'
Size: 427008 Blocks: 420 IO Block: 65536 regular file
Device: 12f0a5c0h/317760960d Inode: 281474976726615 Links: 2
Access: (0770/-rwxrwx---) Uid: (4294967294/TrustedInstaller) Gid: (4294967294/TrustedInstaller)
Access: 2009-07-14 01:27:10.125698800 +0200
Modify: 2009-07-14 03:39:29.639000000 +0200
Change: 2013-10-16 16:50:39.470163200 +0200
Birth: 2009-07-14 01:27:10.125698800 +0200
64-@@ regedit # regedit FAILS TO OPEN *****
E:\Cygwin64\bin\bash: /drv/c/WINDOWS/regedit: Permission denied
64-@@ cygstart regedit # regedit opens normally
---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
Using my 64-bits Cygwin installation (MinTTY, >>>>> ELEVATED <<<<< bash) at e:/Cygwin64
64-@@# uname -a
CYGWIN_NT-6.1 Seven 1.7.30s(0.272/5/3) 20140426 17:41:38 x86_64 Cygwin
64-@@# echo $PATH
/usr/local/bin:/usr/bin:/drv/c/WINDOWS/system32:/drv/c/WINDOWS:/drv/c/WINDOWS/System32/Wbem:/home/Henri/bin
64-@@# pwd
/home/Henri
64-@@# which -a regedit
/drv/c/WINDOWS/regedit
64-@@# ls -l /drv/c/WINDOWS/regedit
-rwxrwx---+ 2 TrustedInstaller TrustedInstaller 427008 Jul 14 2009 /drv/c/WINDOWS/regedit
64-@@# stat /drv/c/WINDOWS/regedit
File: `/drv/c/WINDOWS/regedit'
Size: 427008 Blocks: 420 IO Block: 65536 regular file
Device: 12f0a5c0h/317760960d Inode: 281474976726615 Links: 2
Access: (0770/-rwxrwx---) Uid: (4294967294/TrustedInstaller) Gid: (4294967294/TrustedInstaller)
Access: 2009-07-14 01:27:10.125698800 +0200
Modify: 2009-07-14 03:39:29.639000000 +0200
Change: 2013-10-16 16:50:39.470163200 +0200
Birth: 2009-07-14 01:27:10.125698800 +0200
64-@@# regedit # regedit opens normally
64-@@# cygstart regedit # dito
---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
Using my 32-bits Cygwin installation (MinTTY, bash) at e:/Cygwin
@@ uname -a
CYGWIN_NT-6.1-WOW64 Seven 1.7.30s(0.272/5/3) 20140426 17:41:38 i686 Cygwin
@@ echo $PATH
/usr/local/bin:/usr/bin:/drv/c/WINDOWS/System32:/drv/c/WINDOWS:/drv/c/WINDOWS/System32/Wbem:/home/Henri/bin
@@ pwd
/home/Henri
@@ which -a regedit
/drv/c/WINDOWS/System32/regedit
/drv/c/WINDOWS/regedit
@@ ls -l /drv/c/WINDOWS/System32/regedit
-rwxrwx---+ 2 TrustedInstaller TrustedInstaller 398336 Jul 14 2009 /drv/c/WINDOWS/System32/regedit
# a different file than before, apparently ...
@@ stat /drv/c/WINDOWS/System32/regedit
File: `/drv/c/WINDOWS/System32/regedit'
Size: 398336 Blocks: 392 IO Block: 65536 regular file
Device: 12f0a5c0h/317760960d Inode: 281474976748756 Links: 2
Access: (0770/-rwxrwx---) Uid: (4294967294/TrustedInstaller) Gid: (4294967294/TrustedInstaller)
Access: 2009-07-14 01:17:08.803392200 +0200
Modify: 2009-07-14 03:14:30.457000000 +0200
Change: 2013-10-10 07:23:25.639492800 +0200
Birth: 2009-07-14 01:17:08.803392200 +0200
@@ regedit # regedit opens normally
@@ cygstart regedit # dito
---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
Using the 64-bits cmd.exe from MS:
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
64-C:\Users\Henri>e:\Cygwin64\bin\which -a regedit
/drv/c/Windows/regedit
64-C:\Users\Henri>e:\Cygwin64\bin\ls -l /drv/c/Windows/regedit*
-rwxrwx---+ 2 TrustedInstaller TrustedInstaller 427008 Jul 14 2009 /drv/c/Windows/regedit.exe
64-C:\Users\Henri>e:\Cygwin64\bin\stat /drv/c/Windows/regedit*
File: `/drv/c/Windows/regedit.exe'
Size: 427008 Blocks: 420 IO Block: 65536 regular file
Device: 12f0a5c0h/317760960d Inode: 281474976726615 Links: 2
Access: (0770/-rwxrwx---) Uid: (4294967294/TrustedInstaller) Gid: (4294967294/TrustedInstaller)
Access: 2009-07-14 01:27:10.125698800 +0200
Modify: 2009-07-14 03:39:29.639000000 +0200
Change: 2013-10-16 16:50:39.470163200 +0200
Birth: 2009-07-14 01:27:10.125698800 +0200
64-C:\Users\Henri>regedit # regedit opens normally
64-C:\Users\Henri>start regedit # dito
64-C:\Users\Henri>e:\Cygwin64\cygstart regedit # dito
======
--
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?
2014-05-10 13:42 Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail? Houder
@ 2014-05-10 14:11 ` Chris J. Breisch
2014-05-12 12:50 ` Houder
2014-05-13 15:10 ` Houder
0 siblings, 2 replies; 11+ messages in thread
From: Chris J. Breisch @ 2014-05-10 14:11 UTC (permalink / raw)
To: cygwin
Houder wrote:
> Hi,
>
> 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 ...
[snip]
> E:\Cygwin64\bin\bash: /drv/c/WINDOWS/regedit: Permission denied
I can not duplicate your behavior. I can not invoke regedit from any
non-elevated bash prompt, regardless of whether it is 32-bit or 64-bit.
I get the above error in both cases.
--
Chris J. Breisch
--
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?
2014-05-10 14:11 ` Chris J. Breisch
@ 2014-05-12 12:50 ` Houder
2014-05-12 12:51 ` Andrey Repin
2014-05-12 13:01 ` Corinna Vinschen
2014-05-13 15:10 ` Houder
1 sibling, 2 replies; 11+ messages in thread
From: Houder @ 2014-05-12 12:50 UTC (permalink / raw)
To: cygwin
> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?
2014-05-12 12:50 ` Houder
@ 2014-05-12 12:51 ` Andrey Repin
2014-05-12 17:13 ` Houder
2014-05-12 13:01 ` Corinna Vinschen
1 sibling, 1 reply; 11+ messages in thread
From: Andrey Repin @ 2014-05-12 12:51 UTC (permalink / raw)
To: Houder, cygwin
Greetings, Houder!
> 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.
No surprise here. To reach 64-bit regedit (and other utilities) from 32-bit
application, you have to address it through %SystemRoot%\Sysnative path.
> Note: 32-bits cmd and 64-bits cmd report c:/Windows/regedit.exe as the SAME
> file. Which, of course, made me wonder ...
I wonder, how do you check that?
> 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).
How did you found that?
--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 12.05.2014, <16:34>
Sorry for my terrible english...
--
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?
2014-05-12 12:50 ` Houder
2014-05-12 12:51 ` Andrey Repin
@ 2014-05-12 13:01 ` Corinna Vinschen
2014-05-12 13:15 ` Shaddy Baddah
2014-05-12 17:31 ` Houder
1 sibling, 2 replies; 11+ messages in thread
From: Corinna Vinschen @ 2014-05-12 13:01 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 1914 bytes --]
On May 12 14:20, Houder wrote:
> 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'
Doesn't matter. The problem is that elevating is a special procedure,
requiring a special form of ShellExecuteEx function, which doesn't
integrate well with the requirements of POSIX fork/exec. Therefore
Cygwin never calls ShellExecuteEx to fork/exec an application, rather it
calls CreateProcess/CreateProcessAsUser, both of which don't provide a
way to elevate a process. Therefore, to elevate a process from a Cygwin
shell, the shell must already run elevated (e.g., right click on "Cygwin
Terminal" -> "Run as Administrator...").
What's really annoying: RegEdit's mainfest does not request "asAdmin"
rights. Rather it only requests "MaximumAllowed". One would think this
means that a CreateProcess call would simply continue with the current
permissions of the user. Not so, unfortunately.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?
2014-05-12 13:01 ` Corinna Vinschen
@ 2014-05-12 13:15 ` Shaddy Baddah
2014-05-12 13:23 ` Corinna Vinschen
2014-05-12 18:47 ` Houder
2014-05-12 17:31 ` Houder
1 sibling, 2 replies; 11+ messages in thread
From: Shaddy Baddah @ 2014-05-12 13:15 UTC (permalink / raw)
To: cygwin
Hi,
On 2014-05-12 22:50+1000, Corinna Vinschen wrote:
> On May 12 14:20, Houder wrote:
>> 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'
>
> Doesn't matter. The problem is that elevating is a special procedure,
> requiring a special form of ShellExecuteEx function, which doesn't
> integrate well with the requirements of POSIX fork/exec. Therefore
> Cygwin never calls ShellExecuteEx to fork/exec an application, rather it
> calls CreateProcess/CreateProcessAsUser, both of which don't provide a
> way to elevate a process. Therefore, to elevate a process from a Cygwin
> shell, the shell must already run elevated (e.g., right click on "Cygwin
> Terminal" -> "Run as Administrator...").
>
> What's really annoying: RegEdit's mainfest does not request "asAdmin"
> rights. Rather it only requests "MaximumAllowed". One would think this
> means that a CreateProcess call would simply continue with the current
> permissions of the user. Not so, unfortunately.
I am not sure which Edition it started in, but I believe regedit opens
as the invoking user from Windows 8.1 at least (perhaps 8, I have a
vague recollection).
--
Regards,
Shaddy
--
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?
2014-05-12 13:15 ` Shaddy Baddah
@ 2014-05-12 13:23 ` Corinna Vinschen
2014-05-12 18:47 ` Houder
1 sibling, 0 replies; 11+ messages in thread
From: Corinna Vinschen @ 2014-05-12 13:23 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 2237 bytes --]
On May 12 23:00, Shaddy Baddah wrote:
> On 2014-05-12 22:50+1000, Corinna Vinschen wrote:
> >On May 12 14:20, Houder wrote:
> >> - 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'
> >
> >Doesn't matter. The problem is that elevating is a special procedure,
> >requiring a special form of ShellExecuteEx function, which doesn't
> >integrate well with the requirements of POSIX fork/exec. Therefore
> >Cygwin never calls ShellExecuteEx to fork/exec an application, rather it
> >calls CreateProcess/CreateProcessAsUser, both of which don't provide a
> >way to elevate a process. Therefore, to elevate a process from a Cygwin
> >shell, the shell must already run elevated (e.g., right click on "Cygwin
> >Terminal" -> "Run as Administrator...").
> >
> >What's really annoying: RegEdit's mainfest does not request "asAdmin"
> >rights. Rather it only requests "MaximumAllowed". One would think this
> >means that a CreateProcess call would simply continue with the current
> >permissions of the user. Not so, unfortunately.
>
> I am not sure which Edition it started in, but I believe regedit opens
> as the invoking user from Windows 8.1 at least (perhaps 8, I have a
> vague recollection).
Not on my Windows 8.1. Here's the excerpt from regedit's manifest:
"<trustInfo xmlns=""urn:schemas-microsoft-com:asm.v3"">\r\n"
" <security>\r\n"
" <requestedPrivileges>\r\n"
" <requestedExecutionLevel\r\n"
" level=""highestAvailable""\r\n"
" uiAccess=""false""\r\n"
" />\r\n"
" </requestedPrivileges>\r\n"
" </security>\r\n"
"</trustInfo>\r\n"
Ok, so it's called "highestAvailable", not "MaximumAllowed", but you
get the idea. If I call regedit from the non-elevated command line
I get:
$ regedit
/cygdrive/c/WINDOWS/regedit: Permission denied.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?
2014-05-12 12:51 ` Andrey Repin
@ 2014-05-12 17:13 ` Houder
0 siblings, 0 replies; 11+ messages in thread
From: Houder @ 2014-05-12 17:13 UTC (permalink / raw)
To: cygwin
Hi Andrey,
>> 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.
>
> No surprise here. To reach 64-bit regedit (and other utilities) from 32-bit
> application, you have to address it through %SystemRoot%\Sysnative path.
Hold on. I wrote '/drv/c/Windows/regedit.exe' (irrespective of its bit-ness).
BUT! See bottom of this message.
>
>> Note: 32-bits cmd and 64-bits cmd report c:/Windows/regedit.exe as the SAME
>> file. Which, of course, made me wonder ...
>
> I wonder, how do you check that?
C:\Users\Henri> dir /tc /4 c:\Windows\regedit.exe # using 32-bits cmd
Volume in drive C has no label.
Volume Serial Number is 12F0-A5C0
Directory of c:\Windows
14-07-2009 01:27 427.008 regedit.exe
C:\Users\Henri> dir /tc /4 c:\Windows\regedit.exe # using 64-bits cmd
Volume in drive C has no label.
Volume Serial Number is 12F0-A5C0
Directory of c:\Windows
14-07-2009 01:27 427.008 regedit.exe
Size and date/time of creation are the same.
>> 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).
>
> How did you found that?
For instance, here
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384187%28v=vs.85%29.aspx
it said
Access to %windir%\regedit.exe is redirected to %windir%\SysWOW64\regedit.exe (in case of
32-bits application)
The current situation on my W7 does NOT agree with the above statement.
Henri
-----
Here it shows that 32-bits Cygwin "sees" (i.c. ls, stat) a different file at /drv/c/Windows ...
Using my 32-bits Cygwin installation (DOS-box, bash) at e:/Cygwin
@@ ls -l /drv/c/Windows/regedit
-rwxrwx---+ 2 TrustedInstaller TrustedInstaller 398336 Jul 14 2009 /drv/c/Windows/regedit
@@ stat /drv/c/Windows/regedit
File: `/drv/c/Windows/regedit'
Size: 398336 Blocks: 392 IO Block: 65536 regular file
Device: 12f0a5c0h/317760960d Inode: 281474976748756 Links: 2
Access: (0770/-rwxrwx---) Uid: (4294967294/TrustedInstaller) Gid: (4294967294/TrustedInstaller)
Access: 2009-07-14 01:17:08.803392200 +0200
Modify: 2009-07-14 03:14:30.457000000 +0200
Change: 2014-05-11 18:34:40.326326000 +0200
Birth: 2009-07-14 01:17:08.803392200 +0200
Using my 64-bits Cygwin installation (DOS-box, bash) at e:/Cygwin64:
64-@@ ls -l /drv/c/Windows/regedit
-rwxrwx---+ 2 TrustedInstaller TrustedInstaller 427008 Jul 14 2009 /drv/c/Windows/regedit
64-@@ stat /drv/c/Windows/regedit
File: `/drv/c/Windows/regedit'
Size: 427008 Blocks: 420 IO Block: 65536 regular file
Device: 12f0a5c0h/317760960d Inode: 281474976726615 Links: 2
Access: (0770/-rwxrwx---) Uid: (4294967294/TrustedInstaller) Gid: (4294967294/TrustedInstaller)
Access: 2009-07-14 01:27:10.125698800 +0200
Modify: 2009-07-14 03:39:29.639000000 +0200
Change: 2014-05-11 18:35:26.892407800 +0200
Birth: 2009-07-14 01:27:10.125698800 +0200
Note:
- 32-bits Cygwin invokes 64-bits regedit in case of /drv/c/Windows/regedit
(yes, different from the one it "sees" (i.c. ls, stat) !!!!!
- 32-bits Cygwin invokes 32-bits regedit in case of /drv/c/Windows/SysWOW64/regedit
- in case of /drv/c/Windows/System32/regedit: dito
- /drv/c/Windows/SysNative/regedit: does NOT exist!
(the 64-bits version only lives in c:/Windows)
=====
--
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?
2014-05-12 13:01 ` Corinna Vinschen
2014-05-12 13:15 ` Shaddy Baddah
@ 2014-05-12 17:31 ` Houder
1 sibling, 0 replies; 11+ messages in thread
From: Houder @ 2014-05-12 17:31 UTC (permalink / raw)
To: cygwin
Hi Corinna,
Thank you for sharing your expert knowledge!
>> 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'
>
> Doesn't matter. The problem is that elevating is a special procedure,
> requiring a special form of ShellExecuteEx function, which doesn't
> integrate well with the requirements of POSIX fork/exec. Therefore
> Cygwin never calls ShellExecuteEx to fork/exec an application, rather it
> calls CreateProcess/CreateProcessAsUser, both of which don't provide a
> way to elevate a process. Therefore, to elevate a process from a Cygwin
> shell, the shell must already run elevated (e.g., right click on "Cygwin
> Terminal" -> "Run as Administrator...").
>
> What's really annoying: RegEdit's mainfest does not request "asAdmin"
> rights. Rather it only requests "MaximumAllowed". One would think this
> means that a CreateProcess call would simply continue with the current
> permissions of the user. Not so, unfortunately.
Interesting! I can assure you that I am UNfamiliar grounds here :-)
But how do you explain, that I can invoke regedit from 32-bits Cygwin, using
an UNelevated bash?
(both /drv/c/Windows/regedit and /drv/c/Windows/SysWOW64/regedit)
(Sorry, I will look into that myself :-)
Henri
-----
@ stat_uac
The values of the fields are currently:
1. ConsentPromptBehaviorAdmin 0x0
2. ConsentPromptBehaviorUser 0x1
3. EnableInstallerDetection 0x1
4. EnableLUA 0x1
5. EnableSecureUIAPaths 0x1
6. EnableUIADesktopToggle 0x0
7. EnableVirtualization 0x0
8. PromptOnSecureDesktop 0x1
9. ValidateAdminCodeSignatures 0x0
10. FilterAdministratorToken 0x0
@@
=====
--
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?
2014-05-12 13:15 ` Shaddy Baddah
2014-05-12 13:23 ` Corinna Vinschen
@ 2014-05-12 18:47 ` Houder
1 sibling, 0 replies; 11+ messages in thread
From: Houder @ 2014-05-12 18:47 UTC (permalink / raw)
To: cygwin
Hi Shaddy,
> I am not sure which Edition it started in, but I believe regedit opens
> as the invoking user from Windows 8.1 at least (perhaps 8, I have a
> vague recollection).
Once more, for everyone's benefit :-)
Using _MY_ W7 (ConsentPromptBehaviorAdmin field set to zero) ...
= Using "my" administrator account
- from 32-bits cmd (unelevated): regedit opens
- from 64-bits cmd (unelevated): dito
- from 32-bits bash (unelevated): dito
- from 64-bits bash (unelevated): execution denied <====
- from 64-bits bash (elevated): regedit opens
= Using an standard user account
- regedit opens in all cases (w/o requiring consent)
Henri
--
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?
2014-05-10 14:11 ` Chris J. Breisch
2014-05-12 12:50 ` Houder
@ 2014-05-13 15:10 ` Houder
1 sibling, 0 replies; 11+ messages in thread
From: Houder @ 2014-05-13 15:10 UTC (permalink / raw)
To: cygwin
>> 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 ...
> [snip]
>
>> E:\Cygwin64\bin\bash: /drv/c/WINDOWS/regedit: Permission denied
>
> I can not duplicate your behavior. I can not invoke regedit from any
> non-elevated bash prompt, regardless of whether it is 32-bit or 64-bit.
> I get the above error in both cases.
Hi Chris,
Once more, thank you for your input!
Your system shows indeed the "correct" behaviour :-)
On my system the key
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers
had a field e:\Cygwin\bin\bash.exe that read ELEVATECREATEPROCESS
Once the field had been deleted, I got the same behaviour as you did.
(do not ask me how the field with THAT value got there -- I simply do not know)
Henri
--
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2014-05-13 15:05 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-10 13:42 Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail? Houder
2014-05-10 14:11 ` Chris J. Breisch
2014-05-12 12:50 ` Houder
2014-05-12 12:51 ` Andrey Repin
2014-05-12 17:13 ` Houder
2014-05-12 13:01 ` Corinna Vinschen
2014-05-12 13:15 ` Shaddy Baddah
2014-05-12 13:23 ` Corinna Vinschen
2014-05-12 18:47 ` Houder
2014-05-12 17:31 ` Houder
2014-05-13 15:10 ` Houder
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).