Re: Permission issue in Git in DrvFs-mounted network drives

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Sep 20, 2024, 15:51 UTC
Message-ID: <Zu2aHdaw_oDv_dp7@tapette.crustytoothpaste.net>
In-Reply-To: <19205ebb4b9.c2a2da5a2387912.3559118454287459572@orca.pet>

On 2024-09-18 at 16:16:26, Marcos Del Sol Vives wrote:

Show 22 quoted lines

> Under WSL1 (Windows Subsystem for Linux), when using a network share
> mounted via DrvFs, Git fails to add any files to a new or an existing
> repository.
> 
> The reason is that Git tries to open a temporary file as with RW
> permissions but mode 0444, which causes WSL1 (or Samba, unsure who's here
> to blame) to create first an file empty with the read-only DOS attribute set
> that prevents any writes, and then actually trying to opening it in write
> mode, which of course fails.
> 
> Seems to be a pretty common issue that nobody has yet reported officially,
> judging by the amount of posts on Stackoverflow, impacting not only WSL
> but also CIFS under Linux (hence why sending to this mailing list and not
> the Windows-specific one):
> 
>  - https://superuser.com/questions/681196/debugging-git-repo-permissions-on-samba-share
>  - https://superuser.com/questions/1450094/git-on-wsl-commands-fail-despite-permissions-seeming-fine
>  - https://superuser.com/questions/1491499/use-git-on-a-shared-drive-within-wsl
> 
> As a workaround, opening the file with permissions 0600 and then using a
> fchmod with the final desired mode works, which is a very small change that
> should cause no issues under neither real Linux nor WSL:

This behaviour also occurs on some broken NFS mounts. It is, however, explicitly permitted by POSIX to open a file 0444 with O_WRONLY or O_RDWR, and we've traditionally not fixed it for that reason. I would say that WSL1 behaviour is incorrect here. Here's what POSIX says[0]:

  The argument following the oflag argument does not affect whether the
  file is open for reading, writing, or for both.

That is, POSIX forbids failing to open a file for writing because the permissions are 0444, and as such this is not POSIX compliant. Note that the operation must also be atomic; that is, the server can't emulate this by setting the permissions to 0600 and then doing an fchmod internally unless nobody can ever detect the intermediate state.

I think we also probably have a few other codepaths that are affected in the same way and this is maybe just the most noticeable.

Other folks may feel differently about fixing this, but I would suggest against it.

> The WSL team at Microsoft has been already informed as well:
> https://github.com/microsoft/WSL/issues/12051

I've provided some comments in the issue there.

[0] https://pubs.opengroup.org/onlinepubs/9799919799/functions/open.html

-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA