Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?

Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?

[Houder]

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

Re: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?

[Chris J. Breisch]

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

Re: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?

[Houder]

> 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

Re: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?

[Andrey Repin]

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

Re: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?

[Houder]

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

Re: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?

[Corinna Vinschen]

[-- 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 --]

Re: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?

[Shaddy Baddah]

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

Re: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?

[Corinna Vinschen]

[-- 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 --]

Re: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?

[Houder]

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

Re: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?

[Houder]

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

Re: Baffled: is it Cygwin (64-bits) or Windows that causes the invocation of regedit (from bash) to fail?

[Houder]

>> 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