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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



---- El Fri, 20 Sep 2024 22:43:31 +0200,  brian m. carlson  escribió ---- 
> Git could, in theory, accept a patch here.  However, you're also going
> to have lots of other software that breaks in this case, not just Git.
> So it's less useful to patch Git and hundreds of other packages on Linux
> distributions that have relied on the POSIX standard and more useful to
> fix your OS (or maybe switch to WSL2, if that doesn't have the problem).
> Most Linux distros will generally not be interested in fixing this class
> of problem, in my experience.

There is not a significant amount of software that opens files for writing
in read-only mode. Despite using WSL extensively for development, so far
Git has been the only that failed to work.

WSL2 has poor support for accessing local devices (such as serial ports,
something really useful for embedded development like the Proxmark project
where I contribute to) or pipes (which I use to sign commits using a
TPM-backed SSH key), so it's not really an option.

> In addition, chmod doesn't always work under WSL.  I believe it _does_
> work if the drive is mounted with metadata, but some people don't have
> that enabled and I don't know if it works for all drives.  For those
> people, the current code will work, since it doesn't call chmod or
> fchmod, but it will fail with your patch.

I can guarantee you it'll work under WSL, even without metadata, because
I've patched Git on my WSL1 Debian machine by doing the aforementioned
trick and it totally works. Metadata is not even supported on anything but
local NTFS drives.

WSL1, when mounted without metadata, chmod and fchmod calls will not fail
but would instead just ignore the call, *except* when setting mode 444,
400 or any other read-only mode where it will set the FAT/NTFS read-only
attribute:

marcos@desk:/mnt/nas/marcos$ mount | grep nas
\\192.168.0.245\marcos on /mnt/nas/marcos type drvfs (rw,relatime,uid=1000,gid=1000,case=off)
marcos@desk:/mnt/nas/marcos$ touch readonly
marcos@desk:/mnt/nas/marcos$ ls -l readonly
-rwxrwxrwx 1 marcos marcos 0 Sep 21 00:33 readonly
marcos@desk:/mnt/nas/marcos$ chmod 444 readonly
marcos@desk:/mnt/nas/marcos$ ls -l readonly
-r-xr-xr-x 1 marcos marcos 0 Sep 21 00:33 readonly

That is exactly what is causing the issue - two SMB requests are being
issued: one to create the file in read-only mode, and then another to
open it.






[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux