Is chmod supposed to work in MSYS2?

[angelog0]

I notice this:

touch foo
ls -lrt foo
-rw-r--r-- 1 utente NESSUNO 0 16 giu 18.59 foo

chmod go-r foo
ls -lrt foo
-rw-r--r-- 1 utente NESSUNO 0 16 giu 18.59 foo

The same steps on WSL(1) work:

[...]
-rw------- 1 user user      0 giu 16 18:53 foo

[mati865]

FTR, doesn't work in WSL2:

ls -lrt foo
-rwxrwxrwx 1 mateusz mateusz 0 Jun 16 19:09 foo
chmod go-r foo
ls -lrt foo
-rwxrwxrwx 1 mateusz mateusz 0 Jun 16 19:09 foo

[GitMensch]

Definitely works as expected on WSL2:

mateusz@PC:~$ touch foo
mateusz@PC:~$ chmod 777 foo
mateusz@PC:~$ ls -lrt foo
-rwxrwxrwx 1 mateusz mateusz 0 19. Jun 21:48 foo
mateusz@PC:~$ chmod go-r foo
mateusz@PC:~$ ls -lrt foo
-rwx-wx-wx 1 mateusz mateusz 0 19. Jun 21:48 foo

but not at all on MSYS2:

mateusz@PC MINGW64 ~$ touch foo
mateusz@PC MINGW64 ~$ chmod 777 foo
mateusz@PC MINGW64 ~$ ls -lrt foo
-rw-r--r-- 1 mateusz mateusz 0 19. Jun 21:49 foo
mateusz@PC MINGW64 ~$ chmod go-r foo
mateusz@PC MINGW64 ~$ ls -lrt foo
-rw-r--r-- 1 mateusz mateusz 0 19. Jun 21:49 foo

@lazka Do you remember why you've removed the bug label?

[Biswa96]

chmod is not supposed to work in msys2. To change file permission, use icacls or takeown like commands which are specific to Microsoft Windows OS.

[GitMensch]

The good thing is: we now have an answer in this issue about the status quo. The question is: why should it not work (it could, for example be replaced by a wrapper around the noted commands).

[Biswa96]

I am not sure "why" but I did not find any usefulness of chmod or chown in Windows environment. If the file has shebang it automatically becomes executable. Others may explain the reason.

[elieux]

The motivation is as follows: The POSIX and NTFS/Windows permission models differ in ways that make it difficult to translate between them correctly AND succintly. The Cygwin folks are definitely doing a good job, but it's not without issues (IIRC f.i. the Windows/Explorer file security dialog still trips over the Cygwin-generated ACLs). The alternative mode (noacl) makes permissions work seamlessly by just letting Windows manage them and only ever reading them. Since the main goal of MSYS2's emulation layer is just to enable native Win32 software, there doesn't seem to be a point in going for the full bidirectional translation.

[dscho]

FWIW there is a Git for Windows PR to copy mode bits from/to NTFS volumes in a WSL-compatible way, but those bits will definitely be ignored by Cygwin.

[Biswa96]

but those bits will definitely be ignored by Cygwin.

Aren't those NTFS extended attributes be removed when the file is modified? i.e. one of the drawbacks of WSL1.

[dscho]

Aren't those NTFS extended attributes be removed when the file is modified?

They are not removed when the file is modified.

However, many Unix programs do not actually modify files: they write new, temporary files, and then force-rename them to the actual file name. And yes, that pattern will lose the extended attributes unless the Unix program is written with POSIX extended attributes in mind.

[sskras]

@elieux commented last week:

The motivation is as follows: The POSIX and NTFS/Windows permission models differ in ways that make it difficult to translate between them correctly AND succintly. ... Since the main goal of MSYS2's emulation layer is just to enable native Win32 software, there doesn't seem to be a point in going for the full bidirectional translation.

@elieux, thanks for the nice summary. The only thing that I wonder about is:

– Do anyone ever has asked for the mode support to be bidirectional?

IMO folks expecting real change from chmod has little to zero interest in carrying standard Windows operations that way.

[sskras]

This leads me to the conclusion:

• some folks* seeks for the maximum POSIX support on Windows.
• MSYS2 project seeks to minimize the POSIX support on Windows

[*] Folks like @angelog0, @GitMensch, maybe @dlmiles from https://github.com/msys2/MSYS2-packages/pull/3695#issuecomment-1562986097, and surely me.

I see this as an opposing directions of both camps (even as a conflict of interests).

In such situations I always try to suggest to look at the @midipix-project. So as not to waste each others time. In midipix chmod here works right away:

Attention points about using midipix:

• The mode storing mechanics are different from Cygwin (these two environment are not compatible)
• The project is still pre-alpha:
  • includes a bit old build of MinTTY (v2.8.1)
  • quite minimal population of /proc
  • has no installer (requires installing / decompressing files by hand),
  • has a bit unusual build system / workflow,
  • build requires cross-compilation from a Linux machine.

And I invite everyone interested to participate in it (rather than bug the MSYS2 folks:) Cheers!

[SlySven]

There are some situations though where file permissions become problematic for specific applications - one that comes to mind is openssh (or rather the scp utility with it) which requires that the private key is stored in a file that only the user can read - which a colleague of mine on a mutual project found out when he was trying to upload that key to our project's website...

[sskras]

one that comes to mind is openssh (or rather the scp utility with it) which requires that the private key is stored in a file that only the user can read

@SlySven, for me MSYS2 version of SSH client programs work just fine without having to tinker with permission.

Then you could use OS-native, pure Win32 ports of these programs. They come with Windows since some w10 build circa 2018 or so:

https://woshub.com/connect-to-windows-via-ssh/ https://vipinyadav.com/blog/how-to-use-ssh-and-scp-windows-10-file-folder-upload/

My other suggestion remains: use Cygwin. Or even better try using Midipix, although it requires manual cross-compilation + some additional patching related to its' RNG implementation or so for the SSH client programs to work.