Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[BUG] MSYS2 fails to access Windows reparse points with IO_REPARSE_TAG_APPEXECLINK #1943

Open
saschanaz opened this issue May 7, 2020 · 6 comments
Open

[BUG] MSYS2 fails to access Windows reparse points with IO_REPARSE_TAG_APPEXECLINK #1943

saschanaz opened this issue May 7, 2020 · 6 comments

Comments

@saschanaz
Copy link

saschanaz commented May 7, 2020 •
edited

Describe the bug

MSYS shell fails to run UWP apps with "Permission denied" error.

Steps to Reproduce the Problem

  1. Install MSYS2 from https://www.msys2.org/
  2. Install Python 3 from https://www.microsoft.com/store/productId/9MSSZTT1N39L
  3. Run /c/Users/Kagami/AppData/Local/Microsoft/WindowsApps/python3.exe from MSYS2

Expected behavior: It should run Python 3

Additional Context: Operating System, Screenshots

If applicable, add screenshots to help explain your problem.

  • OS: Windows 10 Pro version 2004 64bit

image

image

UWP apps creates reparse points for their executables in /c/Users/Kagami/AppData/Local/Microsoft/WindowsApps/, while MSYS fails to reparse them.

See the PowerShell side of patch: PowerShell/PowerShell#10331
@saschanaz saschanaz added the bug label May 7, 2020
@Biswa96
Copy link
Member

Biswa96 commented May 7, 2020

Read the error carefully. It says "Permission denied". Windows UWP realm is restricted from outer world unless the developer adds the permission in AppxManifest file, like Windows Terminal does.

@saschanaz
Copy link
Author

Windows UWP realm is restricted from outer world unless the developer adds the permission in AppxManifest file

I think that mainly applies when the UWP app wants to access the system, not vise versa. Especially when cmd and pwsh can just access it.

@saschanaz saschanaz changed the title [BUG] MSYS2 fails to access Microsoft Store-distributed Python 3 [BUG] MSYS2 fails to access Microsoft Store-distributed Python 3 while Windows shells can May 11, 2020
@saschanaz saschanaz changed the title [BUG] MSYS2 fails to access Microsoft Store-distributed Python 3 while Windows shells can [BUG] MSYS2 fails to access Windows reparse points with IO_REPARSE_TAG_APPEXECLINK May 23, 2020
@saschanaz
Copy link
Author

saschanaz commented May 23, 2020 •
edited

Added more details that show this is an MSYS bug.

@saschanaz
Copy link
Author

saschanaz commented May 23, 2020 •
edited

It seems this part should be fixed to support the new tag.

https://github.com/msys2/Cygwin/blob/master/winsup/cygwin/path.cc#L2534-L2618

Edit: Okay, this is a cygwin bug.

@davinci26 davinci26 mentioned this issue May 29, 2020
Merged
@rimrul rimrul mentioned this issue Jun 9, 2020
Closed
1 task
@lazka lazka removed the bug label Oct 28, 2020
@KalleOlaviNiemitalo KalleOlaviNiemitalo mentioned this issue Dec 29, 2020
Closed
dscho added a commit to dscho/msys2-runtime that referenced this issue Mar 12, 2021
@dscho
Allow executing Windows Store's "app execution aliases"
0a9ee3e 
The Windows Store version of Python (and apparently other Windows Store
applications) install a special reparse point called "app execution
alias" into the user's `PATH`.

These applications can be executed without any problem, but they cannot
be read as if they were files. This trips up Cygwin's beautiful logic that
tries to determine whether we're about to execute a Cygwin executable or
not: instead of executing the application, it will fail, saying
"Permission denied".

Let's detect this situation (`NtOpenFile()` helpfully says that this
operation is not supported on this reparse point type), and simply skip
the logic: Windows Store apps are not Cygwin executables (and even if
they were, it is unlikely that they would come with a compatible
`cygwin1.dll` or `msys-2.0.dll`).

This fixes msys2/MSYS2-packages#1943

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho added a commit to dscho/msys2-runtime that referenced this issue Mar 12, 2021
@dscho
Allow executing Windows Store's "app execution aliases"
647dff4 
The Windows Store version of Python (and apparently other Windows Store
applications) install a special reparse point called "app execution
alias" into the user's `PATH`.

These applications can be executed without any problem, but they cannot
be read as if they were files. This trips up Cygwin's beautiful logic that
tries to determine whether we're about to execute a Cygwin executable or
not: instead of executing the application, it will fail, saying
"Permission denied".

Let's detect this situation (`NtOpenFile()` helpfully says that this
operation is not supported on this reparse point type), and simply skip
the logic: Windows Store apps are not Cygwin executables (and even if
they were, it is unlikely that they would come with a compatible
`cygwin1.dll` or `msys-2.0.dll`).

This fixes msys2/MSYS2-packages#1943

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho dscho mentioned this issue Mar 12, 2021
Closed
github-cygwin pushed a commit to cygwin/cygwin that referenced this issue Mar 23, 2021
@dscho @github-cygwin
Cygwin: Allow executing Windows Store's "app execution aliases"
2533912 
The Windows Store version of Python (and apparently other Windows Store
applications) install a special reparse point called "app execution
alias" into the user's `PATH`.

These applications can be executed without any problem, but they cannot
be read as if they were files. This trips up Cygwin's beautiful logic that
tries to determine whether we're about to execute a Cygwin executable or
not: instead of executing the application, it will fail, saying
"Permission denied".

Let's detect this situation (`NtOpenFile()` helpfully says that this
operation is not supported on this reparse point type), and simply skip
the logic: Windows Store apps are not Cygwin executables (and even if
they were, it is unlikely that they would come with a compatible
`cygwin1.dll` or `msys-2.0.dll`).

This fixes msys2/MSYS2-packages#1943

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho added a commit to dscho/Cygwin-msys2-fork that referenced this issue Mar 23, 2021
@dscho
Allow executing Windows Store's "app execution aliases"
d869291 
The Windows Store version of Python (and apparently other Windows Store
applications) install a special reparse point called "app execution
alias" into the user's `PATH`.

These applications can be executed without any problem, but they cannot
be read as if they were files. This trips up Cygwin's beautiful logic that
tries to determine whether we're about to execute a Cygwin executable or
not: instead of executing the application, it will fail, saying
"Permission denied".

Let's detect this situation (`NtOpenFile()` helpfully says that this
operation is not supported on this reparse point type), and simply skip
the logic: Windows Store apps are not Cygwin executables (and even if
they were, it is unlikely that they would come with a compatible
`cygwin1.dll` or `msys-2.0.dll`).

This fixes msys2/MSYS2-packages#1943

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
github-cygwin pushed a commit to cygwin/cygwin that referenced this issue Mar 31, 2021
@dscho @kbrow1i
Cygwin: Allow executing Windows Store's "app execution aliases"
e6d1078 
The Windows Store version of Python (and apparently other Windows Store
applications) install a special reparse point called "app execution
alias" into the user's `PATH`.

These applications can be executed without any problem, but they cannot
be read as if they were files. This trips up Cygwin's beautiful logic that
tries to determine whether we're about to execute a Cygwin executable or
not: instead of executing the application, it will fail, saying
"Permission denied".

Let's detect this situation (`NtOpenFile()` helpfully says that this
operation is not supported on this reparse point type), and simply skip
the logic: Windows Store apps are not Cygwin executables (and even if
they were, it is unlikely that they would come with a compatible
`cygwin1.dll` or `msys-2.0.dll`).

This fixes msys2/MSYS2-packages#1943

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@saschanaz
Copy link
Author

saschanaz commented Jul 20, 2021 •
edited

Hi @dscho, I just saw your cygwin patch is released as 3.2.0 🚀! Does it mean this can be closed or is there a remaining work to be done?

@dscho
Copy link
Contributor

dscho commented Jul 21, 2021

There remains work to be done: please verify that your scenario is fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Treat "app execution aliases" as symlinks, and allow executing them dscho/Cygwin-msys2-fork
4 participants
@dscho @lazka @saschanaz @Biswa96