threads / discuss / 38574

odb_mkstemp's 0444 permission broke write/delete access on AFP

Subject: odb_mkstemp's 0444 permission broke write/delete access on AFP

## tl;dr

22 messages between Feb 16, 2015 and Feb 20, 2015.

replies: 21people: 5as markdown or json

Fairuzan Roslan· Feb 16, 2015, 17:54 UTC · lore
Hi,
Somehow the “int mode = 0444;” in odb_mkstemp (environment.c) are causing a lot of issues (unable to unlink/write/rename) to those people who use AFP shares.
In order to be able to write/unlink/delete/rename a file on AFP filesystem the owner of the file must have at least a u+w access to it.
The issue was first introduced in https://github.com/git/git/blob/f80c7ae8fe9c0f3ce93c96a2dccaba34e456e33a/wrapper.c line 284.
To fix these issues the permission need to be adjusted to “int mode = 0644;” in odb_mkstemp (environment.c)
Please let me know if you need further detail.

Regards, Fairuzan

Matthieu Moy· Feb 16, 2015, 18:23 UTC · re: Fairuzan Roslan · lore

Re: odb_mkstemp's 0444 permission broke write/delete access on AFP

Fairuzan Roslan <fairuzan.roslan@gmail.com> writes:
Show 5 quoted lines
> Hi,
>
> Somehow the “int mode = 0444;” in odb_mkstemp (environment.c) are
> causing a lot of issues (unable to unlink/write/rename) to those
> people who use AFP shares.

Is it a problem when using Git (like "git gc" failing to remove old packs), or when trying to remove files outside Git?

> The issue was first introduced in
> https://github.com/git/git/blob/f80c7ae8fe9c0f3ce93c96a2dccaba34e456e33a/wrapper.c
> line 284.

I don't think so. The code before this commit did essentially a chmod 444 on the file, so object files were already read-only before.

The pack files have been read-only since d83c9af5c6a437ddaa9dd27 (Junio, Apr 22 2007).

> To fix these issues the permission need to be adjusted to “int mode =
> 0644;” in odb_mkstemp (environment.c)

The issue is that having object and pack files read-only on the filesystem is a safety feature to prevent accidental modifications (even though it's actually not that effective, since brute-force "sed -i" or "perl -i" still accept to modify read-only files).

So, I'd be a bit reluctant to remove this safety feature for all users if it's only for the benefit of a minority of users. Not that I think the problem shouldn't be fixed, but I'd rather investigate alternate solutions before using this mode = 0644.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Fairuzan Roslan· Feb 16, 2015, 18:41 UTC · re: Matthieu Moy · lore

Re: odb_mkstemp's 0444 permission broke write/delete access on AFP

I don’t see the issue for the owner of his/her own file to have write access. Setting tmp idx & pack files to read-only even for the file owner is not a safety feature.

The real issue here is that in AFP file system can’t even unlink or rename or delete the tmp idx and pack file with no write access after it done, while other file system like ext4,hfs+, etc can.
You should at least give the user the option to set the permission in the config file and not hardcoded the permission in the binary.

Regards, Fairuzan

Show 39 quoted lines
> On Feb 17, 2015, at 2:23 AM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
> 
> Fairuzan Roslan <fairuzan.roslan@gmail.com> writes:
> 
>> Hi,
>> 
>> Somehow the “int mode = 0444;” in odb_mkstemp (environment.c) are
>> causing a lot of issues (unable to unlink/write/rename) to those
>> people who use AFP shares.
> 
> Is it a problem when using Git (like "git gc" failing to remove old
> packs), or when trying to remove files outside Git?
> 
>> The issue was first introduced in
>> https://github.com/git/git/blob/f80c7ae8fe9c0f3ce93c96a2dccaba34e456e33a/wrapper.c
>> line 284.
> 
> I don't think so. The code before this commit did essentially a chmod
> 444 on the file, so object files were already read-only before.
> 
> The pack files have been read-only since d83c9af5c6a437ddaa9dd27 (Junio,
> Apr 22 2007).
> 
>> To fix these issues the permission need to be adjusted to “int mode =
>> 0644;” in odb_mkstemp (environment.c)
> 
> The issue is that having object and pack files read-only on the
> filesystem is a safety feature to prevent accidental modifications (even
> though it's actually not that effective, since brute-force "sed -i" or
> "perl -i" still accept to modify read-only files).
> 
> So, I'd be a bit reluctant to remove this safety feature for all users
> if it's only for the benefit of a minority of users. Not that I think
> the problem shouldn't be fixed, but I'd rather investigate alternate
> solutions before using this mode = 0644.
> 
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/
Matthieu Moy· Feb 16, 2015, 19:08 UTC · re: Fairuzan Roslan · lore

Re: odb_mkstemp's 0444 permission broke write/delete access on AFP

[ Please, don't top post on this list ]
Fairuzan Roslan <fairuzan.roslan@gmail.com> writes:
> I don’t see the issue for the owner of his/her own file to have write
> access.

Object and pack files are not meant to be modified. Hence, they are read-only so that an (accidental) attempt to modify them fails.

> Setting tmp idx & pack files to read-only even for the file owner is
> not a safety feature.
Yes it is. If you do not think so, then please give some arguments.
> You should at least give the user the option to set the permission in
> the config file and not hardcoded the permission in the binary.

This is the kind of thing I meant by "investigate alternate solutions". I have no AFP share to test, so it would help if you answered the question I asked in my previous message:

Show 12 quoted lines
>> On Feb 17, 2015, at 2:23 AM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
>> 
>> Fairuzan Roslan <fairuzan.roslan@gmail.com> writes:
>> 
>>> Hi,
>>> 
>>> Somehow the “int mode = 0444;” in odb_mkstemp (environment.c) are
>>> causing a lot of issues (unable to unlink/write/rename) to those
>>> people who use AFP shares.
>> 
>> Is it a problem when using Git (like "git gc" failing to remove old
>> packs), or when trying to remove files outside Git?
(BTW, why did you try to write/rename pack files?)
-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Fairuzan Roslan· Feb 17, 2015, 03:22 UTC · re: Matthieu Moy · lore

Re: odb_mkstemp's 0444 permission broke write/delete access on AFP

Show 42 quoted lines
> On Feb 17, 2015, at 3:08 AM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
> 
> [ Please, don't top post on this list ]
> 
> Fairuzan Roslan <fairuzan.roslan@gmail.com> writes:
> 
>> I don’t see the issue for the owner of his/her own file to have write
>> access.
> 
> Object and pack files are not meant to be modified. Hence, they are
> read-only so that an (accidental) attempt to modify them fails.
> 
>> Setting tmp idx & pack files to read-only even for the file owner is
>> not a safety feature.
> 
> Yes it is. If you do not think so, then please give some arguments.
> 
>> You should at least give the user the option to set the permission in
>> the config file and not hardcoded the permission in the binary.
> 
> This is the kind of thing I meant by "investigate alternate solutions".
> I have no AFP share to test, so it would help if you answered the
> question I asked in my previous message:
> 
>>> On Feb 17, 2015, at 2:23 AM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
>>> 
>>> Fairuzan Roslan <fairuzan.roslan@gmail.com> writes:
>>> 
>>>> Hi,
>>>> 
>>>> Somehow the “int mode = 0444;” in odb_mkstemp (environment.c) are
>>>> causing a lot of issues (unable to unlink/write/rename) to those
>>>> people who use AFP shares.
>>> 
>>> Is it a problem when using Git (like "git gc" failing to remove old
>>> packs), or when trying to remove files outside Git?
> 
> (BTW, why did you try to write/rename pack files?)
> 
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/
I think its easier if I just show you…

OS : OS X 10.10.0 - 10.10.2 Client : git version 1.9.3 (Apple Git-50) and git version 2.2.1 AFP share : //user@hostname._afpovertcp._tcp.local/installer on /Volumes/installer (afpfs, nodev, nosuid, mounted by user)

1. git clone example

$ git clone https://github.com/robbyrussell/oh-my-zsh.git Cloning into 'oh-my-zsh'... remote: Counting objects: 11830, done. remote: Total 11830 (delta 0), reused 0 (delta 0) Receiving objects: 100% (11830/11830), 2.12 MiB | 481.00 KiB/s, done. Resolving deltas: 100% (6510/6510), done. warning: unable to unlink /Volumes/installer/oh-my-zsh/.git/objects/pack/tmp_pack_zjPxuc: Operation not permitted error: unable to write sha1 filename /Volumes/installer/oh-my-zsh/.git/objects/pack/pack-cceafdc9ef02bc58844138ba543ec6cc38252bb1.pack: Operation not permitted fatal: cannot store pack file fatal: index-pack failed

$ ls -l oh-my-zsh/.git/objects/pack total 5008 -rw------- 1 user staff 32 Feb 17 09:59 pack-cceafdc9ef02bc58844138ba543ec6cc38252bb1.keep -r--r--r-- 1 user staff 332312 Feb 17 09:59 tmp_idx_oUN1sb -r--r--r-- 1 user staff 2223007 Feb 17 09:59 tmp_pack_zjPxuc

$ rm -rf oh-my-zsh/.git/objects/pack/tmp_* rm: oh-my-zsh/.git/objects/pack/tmp_idx_oUN1sb: Operation not permitted rm: oh-my-zsh/.git/objects/pack/tmp_pack_zjPxuc: Operation not permitted

Detail Errors:
1. delete_ref_loose (refs.c) -> unlink_or_msg (wrapper.c) -> "unable to unlink %s: %s"
2. move_temp_to_file (sha1_file.c ) -> “unable to write sha1 filename %s: %s”
2. git pull example

Textual git:master $ git pull remote: Counting objects: 435, done. remote: Compressing objects: 100% (398/398), done. remote: Total 435 (delta 219), reused 18 (delta 12) Receiving objects: 100% (435/435), 1.22 MiB | 756.00 KiB/s, done. Resolving deltas: 100% (219/219), done. warning: unable to unlink .git/objects/pack/tmp_pack_vDaIZa: Operation not permitted error: unable to write sha1 filename .git/objects/pack/pack-977a2dc0f4be3996dc1186e565a30d55d14b5e87.pack: Operation not permitted fatal: cannot store pack file fatal: index-pack failed

Textual git:master $ ls -l .git/objects/pack/tmp_* -r--r--r-- 1 user staff 13252 Feb 17 10:51 .git/objects/pack/tmp_idx_uhnicb -r--r--r-- 1 user staff 1275487 Feb 17 10:51 .git/objects/pack/tmp_pack_vDaIZa

= Same explanation as git clone example
3. git gc example

Textual git:master $ git gc Counting objects: 49691, done. Delta compression using up to 4 threads. Compressing objects: 100% (11347/11347), done. fatal: unable to rename temporary pack file: Operation not permitted error: failed to run repack

Textual git:master $ ls -l .git/objects/pack/tmp_* -r--r--r-- 1 user staff 1392420 Feb 17 10:58 .git/objects/pack/tmp_idx_77nr1b -r--r--r-- 1 user staff 96260304 Feb 17 10:58 .git/objects/pack/tmp_pack_RlAZc9

Detail Error:
1. finish_tmp_packfile (pack-write.c) -> die_errno(“unable to rename temporary pack file”);
If you insist on setting the tmp idx & pack file permission to 0444 at least give it a u+w permission whenever you try to unlink and rename it so it won’t fail.

Regards, Fairuzan

Torsten Bögershausen· Feb 17, 2015, 05:34 UTC · re: Fairuzan Roslan · lore

Re: odb_mkstemp's 0444 permission broke write/delete access on AFP

On 02/17/2015 04:22 AM, Fairuzan Roslan wrote:
Show 80 quoted lines
>> On Feb 17, 2015, at 3:08 AM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
>>
>> [ Please, don't top post on this list ]
>>
>> Fairuzan Roslan <fairuzan.roslan@gmail.com> writes:
>>
>>> I don’t see the issue for the owner of his/her own file to have write
>>> access.
>> Object and pack files are not meant to be modified. Hence, they are
>> read-only so that an (accidental) attempt to modify them fails.
>>
>>> Setting tmp idx & pack files to read-only even for the file owner is
>>> not a safety feature.
>> Yes it is. If you do not think so, then please give some arguments.
>>
>>> You should at least give the user the option to set the permission in
>>> the config file and not hardcoded the permission in the binary.
>> This is the kind of thing I meant by "investigate alternate solutions".
>> I have no AFP share to test, so it would help if you answered the
>> question I asked in my previous message:
>>
>>>> On Feb 17, 2015, at 2:23 AM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
>>>>
>>>> Fairuzan Roslan <fairuzan.roslan@gmail.com> writes:
>>>>
>>>>> Hi,
>>>>>
>>>>> Somehow the “int mode = 0444;” in odb_mkstemp (environment.c) are
>>>>> causing a lot of issues (unable to unlink/write/rename) to those
>>>>> people who use AFP shares.
>>>> Is it a problem when using Git (like "git gc" failing to remove old
>>>> packs), or when trying to remove files outside Git?
>> (BTW, why did you try to write/rename pack files?)
>>
>> --
>> Matthieu Moy
>> http://www-verimag.imag.fr/~moy/
> I think its easier if I just show you…
>
> OS : OS X 10.10.0 - 10.10.2
> Client :  git version 1.9.3 (Apple Git-50) and git version 2.2.1
> AFP share : //user@hostname._afpovertcp._tcp.local/installer on /Volumes/installer (afpfs, nodev, nosuid, mounted by user)
>
> 1. git clone example
>
> $ git clone https://github.com/robbyrussell/oh-my-zsh.git
> Cloning into 'oh-my-zsh'...
> remote: Counting objects: 11830, done.
> remote: Total 11830 (delta 0), reused 0 (delta 0)
> Receiving objects: 100% (11830/11830), 2.12 MiB | 481.00 KiB/s, done.
> Resolving deltas: 100% (6510/6510), done.
> warning: unable to unlink /Volumes/installer/oh-my-zsh/.git/objects/pack/tmp_pack_zjPxuc: Operation not permitted
> error: unable to write sha1 filename /Volumes/installer/oh-my-zsh/.git/objects/pack/pack-cceafdc9ef02bc58844138ba543ec6cc38252bb1.pack: Operation not permitted
> fatal: cannot store pack file
> fatal: index-pack failed
>
> $ ls -l oh-my-zsh/.git/objects/pack
> total 5008
> -rw-------  1 user  staff       32 Feb 17 09:59 pack-cceafdc9ef02bc58844138ba543ec6cc38252bb1.keep
> -r--r--r--  1 user  staff   332312 Feb 17 09:59 tmp_idx_oUN1sb
> -r--r--r--  1 user  staff  2223007 Feb 17 09:59 tmp_pack_zjPxuc
>
> $ rm -rf oh-my-zsh/.git/objects/pack/tmp_*
> rm: oh-my-zsh/.git/objects/pack/tmp_idx_oUN1sb: Operation not permitted
> rm: oh-my-zsh/.git/objects/pack/tmp_pack_zjPxuc: Operation not permitted
>
> Detail Errors:
> 1. delete_ref_loose (refs.c) -> unlink_or_msg (wrapper.c) -> "unable to unlink %s: %s"
> 2. move_temp_to_file (sha1_file.c ) -> “unable to write sha1 filename %s: %s”
>
> 2. git pull example
>
> Textual git:master $ git pull
> remote: Counting objects: 435, done.
> remote: Compressing objects: 100% (398/398), done.
> remote: Total 435 (delta 219), reused 18 (delta 12)
> Receiving objects: 100% (435/435), 1.22 MiB | 756.00 KiB/s, done.
> Resolving deltas: 100% (219/219), done.
> warning: unable to unlink .git/objects/pack/tmp_pack_vDaIZa: Operation not permitted
> error: unable to write sha1 filename .git/objects/pack/pack-977a2dc0f4be3996dc1186e565a30d55d14b5e87.pack: Operation not permitted
I'm somewhat unsure how this is connected to 0444 ?

It seems as if you don't have write permissions for some reasons. (on the higher directory), what does ls -ld .git/objects/pack/ ls -ld .git/objects/ give ?

can you run rm .git/objects/pack/pack-977a2dc0f4be3996dc1186e565a30d55d14b5e87.pack

on the command line ?
Fairuzan Roslan· Feb 17, 2015, 05:54 UTC · re: Torsten Bögershausen · lore

Re: odb_mkstemp's 0444 permission broke write/delete access on AFP

Show 95 quoted lines
> On Feb 17, 2015, at 1:34 PM, Torsten Bögershausen <tboegi@web.de> wrote:
> 
> On 02/17/2015 04:22 AM, Fairuzan Roslan wrote:
>>> On Feb 17, 2015, at 3:08 AM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
>>> 
>>> [ Please, don't top post on this list ]
>>> 
>>> Fairuzan Roslan <fairuzan.roslan@gmail.com> writes:
>>> 
>>>> I don’t see the issue for the owner of his/her own file to have write
>>>> access.
>>> Object and pack files are not meant to be modified. Hence, they are
>>> read-only so that an (accidental) attempt to modify them fails.
>>> 
>>>> Setting tmp idx & pack files to read-only even for the file owner is
>>>> not a safety feature.
>>> Yes it is. If you do not think so, then please give some arguments.
>>> 
>>>> You should at least give the user the option to set the permission in
>>>> the config file and not hardcoded the permission in the binary.
>>> This is the kind of thing I meant by "investigate alternate solutions".
>>> I have no AFP share to test, so it would help if you answered the
>>> question I asked in my previous message:
>>> 
>>>>> On Feb 17, 2015, at 2:23 AM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
>>>>> 
>>>>> Fairuzan Roslan <fairuzan.roslan@gmail.com> writes:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> Somehow the “int mode = 0444;” in odb_mkstemp (environment.c) are
>>>>>> causing a lot of issues (unable to unlink/write/rename) to those
>>>>>> people who use AFP shares.
>>>>> Is it a problem when using Git (like "git gc" failing to remove old
>>>>> packs), or when trying to remove files outside Git?
>>> (BTW, why did you try to write/rename pack files?)
>>> 
>>> --
>>> Matthieu Moy
>>> http://www-verimag.imag.fr/~moy/
>> I think its easier if I just show you…
>> 
>> OS : OS X 10.10.0 - 10.10.2
>> Client :  git version 1.9.3 (Apple Git-50) and git version 2.2.1
>> AFP share : //user@hostname._afpovertcp._tcp.local/installer on /Volumes/installer (afpfs, nodev, nosuid, mounted by user)
>> 
>> 1. git clone example
>> 
>> $ git clone https://github.com/robbyrussell/oh-my-zsh.git
>> Cloning into 'oh-my-zsh'...
>> remote: Counting objects: 11830, done.
>> remote: Total 11830 (delta 0), reused 0 (delta 0)
>> Receiving objects: 100% (11830/11830), 2.12 MiB | 481.00 KiB/s, done.
>> Resolving deltas: 100% (6510/6510), done.
>> warning: unable to unlink /Volumes/installer/oh-my-zsh/.git/objects/pack/tmp_pack_zjPxuc: Operation not permitted
>> error: unable to write sha1 filename /Volumes/installer/oh-my-zsh/.git/objects/pack/pack-cceafdc9ef02bc58844138ba543ec6cc38252bb1.pack: Operation not permitted
>> fatal: cannot store pack file
>> fatal: index-pack failed
>> 
>> $ ls -l oh-my-zsh/.git/objects/pack
>> total 5008
>> -rw-------  1 user  staff       32 Feb 17 09:59 pack-cceafdc9ef02bc58844138ba543ec6cc38252bb1.keep
>> -r--r--r--  1 user  staff   332312 Feb 17 09:59 tmp_idx_oUN1sb
>> -r--r--r--  1 user  staff  2223007 Feb 17 09:59 tmp_pack_zjPxuc
>> 
>> $ rm -rf oh-my-zsh/.git/objects/pack/tmp_*
>> rm: oh-my-zsh/.git/objects/pack/tmp_idx_oUN1sb: Operation not permitted
>> rm: oh-my-zsh/.git/objects/pack/tmp_pack_zjPxuc: Operation not permitted
>> 
>> Detail Errors:
>> 1. delete_ref_loose (refs.c) -> unlink_or_msg (wrapper.c) -> "unable to unlink %s: %s"
>> 2. move_temp_to_file (sha1_file.c ) -> “unable to write sha1 filename %s: %s”
>> 
>> 2. git pull example
>> 
>> Textual git:master $ git pull
>> remote: Counting objects: 435, done.
>> remote: Compressing objects: 100% (398/398), done.
>> remote: Total 435 (delta 219), reused 18 (delta 12)
>> Receiving objects: 100% (435/435), 1.22 MiB | 756.00 KiB/s, done.
>> Resolving deltas: 100% (219/219), done.
>> warning: unable to unlink .git/objects/pack/tmp_pack_vDaIZa: Operation not permitted
>> error: unable to write sha1 filename .git/objects/pack/pack-977a2dc0f4be3996dc1186e565a30d55d14b5e87.pack: Operation not permitted
> I'm somewhat unsure how this is connected to 0444 ?
> 
> It seems as if you don't have write permissions for some reasons.
> (on the higher directory), what does
> ls -ld  .git/objects/pack/
> ls -ld  .git/objects/
> give ?
> 
> can you run
> rm .git/objects/pack/pack-977a2dc0f4be3996dc1186e565a30d55d14b5e87.pack
> 
> on the command line ?

No. I have write permission on all of the folders. drwxr-xr-x 1 user staff 264 Feb 17 11:05 . drwxr-xr-x 1 user staff 264 Jan 30 12:52 ..

It has nothing to do with my folder permissions. Like I said earlier this only happened to people who use AFP shares.
When odb_mkstemp being called and sets the tmp idx & pack files to 0444 and later functions like unlink_or_msg or finish_tmp_packfile tries to unlink or rename those files, it will fail
It would be much faster and easier if you can try it on a AFP shares or I can talk you through it over irc @freenode #git (riaf^)

Regards, Fairuzan

Matthieu Moy· Feb 17, 2015, 08:51 UTC · re: Fairuzan Roslan · lore

Re: odb_mkstemp's 0444 permission broke write/delete access on AFP

Fairuzan Roslan <fairuzan.roslan@gmail.com> writes:
Show 7 quoted lines
> $ git clone https://github.com/robbyrussell/oh-my-zsh.git
> Cloning into 'oh-my-zsh'...
> remote: Counting objects: 11830, done.
> remote: Total 11830 (delta 0), reused 0 (delta 0)
> Receiving objects: 100% (11830/11830), 2.12 MiB | 481.00 KiB/s, done.
> Resolving deltas: 100% (6510/6510), done.
> warning: unable to unlink /Volumes/installer/oh-my-zsh/.git/objects/pack/tmp_pack_zjPxuc: Operation not permitted

This should be fixable from Git itself, by replacing the calls to "unlink" with something like

int unlink_or_chmod(...) {
	if (unlink(...)) {
		chmod(...); // give user write permission
		return unlink(...);
	}
}

This does not add extra cost in the normal case, and would fix this particular issue for afp shares. So, I think that would fix the biggest problem for afp-share users without disturbing others. It seems reasonable to me to do that unconditionnally.

> $ rm -rf oh-my-zsh/.git/objects/pack/tmp_*
> rm: oh-my-zsh/.git/objects/pack/tmp_idx_oUN1sb: Operation not permitted
> rm: oh-my-zsh/.git/objects/pack/tmp_pack_zjPxuc: Operation not permitted

What happens if you do "rm -fr oh-my-zsh/.git/objects/pack/" (i.e. remove the directory, not the files)?

If you can still remove the directory, then I'd say the solution above could be sufficient: the user isn't supposed to interfer with the content of .git/objects other than by using Git, and if he or she does, then asking a chmod prior to an rm seems reasonable.

If you can't, then it's another problematic use-case (basically, you can't just "rm -fr" a whole clone), and then it deserves at least an opt-in configuration to get writable pack files.

(Unfortunately, I suspect we're in the later case)
> If you insist on setting the tmp idx & pack file permission to 0444 at
> least give it a u+w permission whenever you try to unlink and rename
> it so it won’t fail.

Yes. In case you hadn't guessed, this is precisely what I had in mind when I asked "Is it a problem when using Git [...] or when trying to remove files outside Git?".

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Fairuzan Roslan· Feb 17, 2015, 16:58 UTC · re: Matthieu Moy · lore

Re: odb_mkstemp's 0444 permission broke write/delete access on AFP

Show 56 quoted lines
> On Feb 17, 2015, at 4:51 PM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
> 
> Fairuzan Roslan <fairuzan.roslan@gmail.com> writes:
> 
>> $ git clone https://github.com/robbyrussell/oh-my-zsh.git
>> Cloning into 'oh-my-zsh'...
>> remote: Counting objects: 11830, done.
>> remote: Total 11830 (delta 0), reused 0 (delta 0)
>> Receiving objects: 100% (11830/11830), 2.12 MiB | 481.00 KiB/s, done.
>> Resolving deltas: 100% (6510/6510), done.
>> warning: unable to unlink /Volumes/installer/oh-my-zsh/.git/objects/pack/tmp_pack_zjPxuc: Operation not permitted
> 
> This should be fixable from Git itself, by replacing the calls to
> "unlink" with something like
> 
> int unlink_or_chmod(...) {
> 	if (unlink(...)) {
> 		chmod(...); // give user write permission
> 		return unlink(...);
> 	}
> }
> 
> This does not add extra cost in the normal case, and would fix this
> particular issue for afp shares. So, I think that would fix the biggest
> problem for afp-share users without disturbing others. It seems
> reasonable to me to do that unconditionnally.
> 
>> $ rm -rf oh-my-zsh/.git/objects/pack/tmp_*
>> rm: oh-my-zsh/.git/objects/pack/tmp_idx_oUN1sb: Operation not permitted
>> rm: oh-my-zsh/.git/objects/pack/tmp_pack_zjPxuc: Operation not permitted
> 
> What happens if you do "rm -fr oh-my-zsh/.git/objects/pack/" (i.e.
> remove the directory, not the files)?
> 
> If you can still remove the directory, then I'd say the solution above
> could be sufficient: the user isn't supposed to interfer with the
> content of .git/objects other than by using Git, and if he or she does,
> then asking a chmod prior to an rm seems reasonable.
> 
> If you can't, then it's another problematic use-case (basically, you
> can't just "rm -fr" a whole clone), and then it deserves at least an
> opt-in configuration to get writable pack files.
> 
> (Unfortunately, I suspect we're in the later case)
> 
>> If you insist on setting the tmp idx & pack file permission to 0444 at
>> least give it a u+w permission whenever you try to unlink and rename
>> it so it won’t fail.
> 
> Yes. In case you hadn't guessed, this is precisely what I had in mind
> when I asked "Is it a problem when using Git [...] or when trying to
> remove files outside Git?".
> 
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/

Yes. It’s a problem when using Git where it fails to unlink and rename the tmp idx and pack files. The reason I tries to rm -rf the tmp_idx_XXXXXX and tmp_pack_XXXXXX is to proof a point why Git fails

Perhaps my explanation wasn’t clear enough. Maybe it’s hard for you to understand without having to test it yourself on a AFP filesystem.
Let me explain why AFP filesystem is more strict and different from your typical filesystem like ext4,hfs+,etc.

$ mkdir testdir; chmod 0755 testdir; touch testdir/testfile; chmod 0444 testdir/testfile; ls -la testdir total 0 drwxr-xr-x 1 user staff 264 Feb 18 00:26 . drwx------ 1 user staff 264 Feb 18 00:26 .. -r--r--r-- 1 user staff 0 Feb 18 00:26 testfile

$ rm -rf testdir rm: testdir/testfile: Operation not permitted rm: testdir: Directory not empty

$ chmod +w testdir/testfile; ls -la testdir total 0 drwxr-xr-x 1 riaf staff 264 Feb 18 00:26 . drwx------ 1 riaf staff 264 Feb 18 00:26 .. -rw-r—r-- 1 riaf staff 0 Feb 18 00:26 testfile

$ rm -rf testdir <—— No error message
This show that you cannot delete a directory or a file without a write permission in AFP filesystem.

The problem with Git failing is not because its inability to delete a directory but its inability to unlink and rename tmp_idx_XXXXXX and tmp_pack_XXXXXX because those files were set to 0444 by odb_mkstemp. Try google for “Git AFP” and you will see a lot people are facing with the same problem.

Regarding your suggestion, yes I think it would work but you have to take care (chmod) every calls that rename or unlink or delete files with 0444 permission.

Regards, Fairuzan

Torsten Bögershausen· Feb 17, 2015, 17:54 UTC · re: Fairuzan Roslan · lore

Re: odb_mkstemp's 0444 permission broke write/delete access on AFP

On 17/02/15 17:58, Fairuzan Roslan wrote:
Show 75 quoted lines
> 
>> On Feb 17, 2015, at 4:51 PM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
>>
>> Fairuzan Roslan <fairuzan.roslan@gmail.com> writes:
>>
>>> $ git clone https://github.com/robbyrussell/oh-my-zsh.git
>>> Cloning into 'oh-my-zsh'...
>>> remote: Counting objects: 11830, done.
>>> remote: Total 11830 (delta 0), reused 0 (delta 0)
>>> Receiving objects: 100% (11830/11830), 2.12 MiB | 481.00 KiB/s, done.
>>> Resolving deltas: 100% (6510/6510), done.
>>> warning: unable to unlink /Volumes/installer/oh-my-zsh/.git/objects/pack/tmp_pack_zjPxuc: Operation not permitted
>>
>> This should be fixable from Git itself, by replacing the calls to
>> "unlink" with something like
>>
>> int unlink_or_chmod(...) {
>> 	if (unlink(...)) {
>> 		chmod(...); // give user write permission
>> 		return unlink(...);
>> 	}
>> }
>>
>> This does not add extra cost in the normal case, and would fix this
>> particular issue for afp shares. So, I think that would fix the biggest
>> problem for afp-share users without disturbing others. It seems
>> reasonable to me to do that unconditionnally.
>>
>>> $ rm -rf oh-my-zsh/.git/objects/pack/tmp_*
>>> rm: oh-my-zsh/.git/objects/pack/tmp_idx_oUN1sb: Operation not permitted
>>> rm: oh-my-zsh/.git/objects/pack/tmp_pack_zjPxuc: Operation not permitted
>>
>> What happens if you do "rm -fr oh-my-zsh/.git/objects/pack/" (i.e.
>> remove the directory, not the files)?
>>
>> If you can still remove the directory, then I'd say the solution above
>> could be sufficient: the user isn't supposed to interfer with the
>> content of .git/objects other than by using Git, and if he or she does,
>> then asking a chmod prior to an rm seems reasonable.
>>
>> If you can't, then it's another problematic use-case (basically, you
>> can't just "rm -fr" a whole clone), and then it deserves at least an
>> opt-in configuration to get writable pack files.
>>
>> (Unfortunately, I suspect we're in the later case)
>>
>>> If you insist on setting the tmp idx & pack file permission to 0444 at
>>> least give it a u+w permission whenever you try to unlink and rename
>>> it so it won’t fail.
>>
>> Yes. In case you hadn't guessed, this is precisely what I had in mind
>> when I asked "Is it a problem when using Git [...] or when trying to
>> remove files outside Git?".
>>
>> --
>> Matthieu Moy
>> http://www-verimag.imag.fr/~moy/
> 
> Yes. It’s a problem when using Git where it fails to unlink and rename the tmp idx and pack files.
> The reason I tries to rm -rf the tmp_idx_XXXXXX and tmp_pack_XXXXXX is to proof a point why Git fails
> 
> Perhaps my explanation wasn’t clear enough. Maybe it’s hard for you to understand without having to test it yourself on a AFP filesystem.
> 
> Let me explain why AFP filesystem is more strict and different from your typical filesystem like ext4,hfs+,etc.
> 
> $ mkdir testdir; chmod 0755 testdir; touch testdir/testfile; chmod 0444 testdir/testfile; ls -la testdir
> total 0
> drwxr-xr-x  1 user  staff  264 Feb 18 00:26 .
> drwx------  1 user  staff  264 Feb 18 00:26 ..
> -r--r--r--  1 user  staff    0 Feb 18 00:26 testfile
> 
> $ rm -rf testdir
> rm: testdir/testfile: Operation not permitted
> rm: testdir: Directory not empty
> 
This works on my system (Mac OS 10.9 as server and client)
Show 12 quoted lines
> $ chmod +w testdir/testfile; ls -la testdir
> total 0
> drwxr-xr-x  1 riaf  staff  264 Feb 18 00:26 .
> drwx------  1 riaf  staff  264 Feb 18 00:26 ..
> -rw-r—r--  1 riaf  staff    0 Feb 18 00:26 testfile
> 
> $ rm -rf testdir <—— No error message
> 
> This show that you cannot delete a directory or a file without a write permission in AFP filesystem.
> 
> The problem with Git failing is not because its inability to delete a directory but its inability to unlink and rename tmp_idx_XXXXXX and tmp_pack_XXXXXX because those files were set to 0444 by odb_mkstemp.
> Try google for “Git AFP” and you will see a lot people are facing with the same problem.
Yes, (at least to my knowledge) you seem to be one of the first to report it here, thanks for that.
Show 6 quoted lines
> 
> Regarding your suggestion, yes I think it would work but you have to take care (chmod) every calls that rename or unlink or delete files with 0444 permission.
> 
> Regards,
> Fairuzan
>

The "right" solution is to make a wrapper function, and to re-define unlink() and rename() with help of the preprocessor.

git-compat-util.h has an example for fopen(), so that can be used for a patch.
And no, as I can not reproduce it here, I can only help with reviews or so.
Matthieu Moy· Feb 18, 2015, 08:15 UTC · re: Torsten Bögershausen · lore

Re: odb_mkstemp's 0444 permission broke write/delete access on AFP

Torsten Bögershausen <tboegi@web.de> writes:
Show 7 quoted lines
> On 17/02/15 17:58, Fairuzan Roslan wrote:
>
>> $ rm -rf testdir
>> rm: testdir/testfile: Operation not permitted
>> rm: testdir: Directory not empty
>> 
> This works on my system (Mac OS 10.9 as server and client)

Just to be sure: by "work", you mean "successfully removes the directory", right?

>> The problem with Git failing is not because its inability to delete a directory but its inability to unlink and rename tmp_idx_XXXXXX and tmp_pack_XXXXXX because those files were set to 0444 by odb_mkstemp.
>> Try google for “Git AFP” and you will see a lot people are facing with the same problem.
> Yes, (at least to my knowledge) you seem to be one of the first to report it here, thanks for that.

And now I'm starting to wonder whether other people do have the same issue. Sure, googling "Git AFP" shows a lot of people having problems with Git and AFP, but are they really the same problem?

I googled 'git afp "unable to unlink"', and all results except one point to this thread:

https://www.google.com/search?q=git+afp+%22warning%3A+unable+to+unlink%22
The only one which doesn't actually does not mention afp.
Fairuzan: are you sure you're not the only one having the issue? Can you
give more info on your system (OS version client and server side, ...)?
-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Fairuzan Roslan· Feb 18, 2015, 13:47 UTC · re: Matthieu Moy · lore

Re: odb_mkstemp's 0444 permission broke write/delete access on AFP

Show 15 quoted lines
> On Feb 18, 2015, at 4:15 PM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
> 
> And now I'm starting to wonder whether other people do have the same
> issue. Sure, googling "Git AFP" shows a lot of people having problems
> with Git and AFP, but are they really the same problem?
> 
> I googled 'git afp "unable to unlink"', and all results except one point
> to this thread:
> 
> https://www.google.com/search?q=git+afp+%22warning%3A+unable+to+unlink%22
> 
> The only one which doesn't actually does not mention afp.
> 
> Fairuzan: are you sure you're not the only one having the issue? Can you
> give more info on your system (OS version client and server side, …)?
No I don’t think I’m the only one with the permission issue here but I’m sure many people prefer using smb over afp
Client: OS X 10.9 - 10.10.2
git client: git version 1.9.3 (Apple Git-50) and git version 2.2.1

Server : Linux 3.2.40 (Synology DSM 5.1) AFP : Netatalk afpd 3.1.1

From what I have tested whenever a file’s permission set to read-only on the AFP shares a user immutable flag were set as well hence why any action such as unlink or rename failed.

$ ls -laO total 0 drwxr-xr-x 1 user staff - 264 Feb 18 21:31 . drwx------ 1 user staff - 264 Feb 18 21:31 .. -rw-r--r-- 1 user staff - 0 Feb 18 21:31 testfile $ chmod 0444 testfile; ls -laO total 0 drwxr-xr-x 1 user staff - 264 Feb 18 21:31 . drwx------ 1 user staff - 264 Feb 18 21:32 .. -r--r--r-- 1 user staff uchg 0 Feb 18 21:31 testfile

I believe this to stop a read-only file to be modified by the user in  Netatalk AFPD.

$ chmod 0644 testfile; ls -laO total 0 drwxr-xr-x 1 user staff - 264 Feb 18 21:32 . drwx------ 1 user staff - 264 Feb 18 21:43 .. -rw-r--r-- 1 user staff - 0 Feb 18 21:31 testfile

Changing the permission to read-write will remove the user immutable flag.

Regards, Fairuzan

Matthieu Moy· Feb 18, 2015, 14:05 UTC · re: Fairuzan Roslan · lore

Re: odb_mkstemp's 0444 permission broke write/delete access on AFP

Fairuzan Roslan <fairuzan.roslan@gmail.com> writes:
Show 5 quoted lines
> Client: OS X 10.9 - 10.10.2
> git client: git version 1.9.3 (Apple Git-50) and git version 2.2.1
>
> Server : Linux 3.2.40 (Synology DSM 5.1)
> AFP : Netatalk afpd 3.1.1
Any chance you can test this with a Mac OS server?

Perhaps because the server is not a Mac OS, it doesn't have the uchg flag, and maps it to the w bit in the POSIX permission system (this is pure speculation from me).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Fairuzan Roslan· Feb 18, 2015, 14:23 UTC · re: Matthieu Moy · lore

Re: odb_mkstemp's 0444 permission broke write/delete access on AFP

Show 19 quoted lines
> On Feb 18, 2015, at 10:05 PM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
> 
> Fairuzan Roslan <fairuzan.roslan@gmail.com> writes:
> 
>> Client: OS X 10.9 - 10.10.2
>> git client: git version 1.9.3 (Apple Git-50) and git version 2.2.1
>> 
>> Server : Linux 3.2.40 (Synology DSM 5.1)
>> AFP : Netatalk afpd 3.1.1
> 
> Any chance you can test this with a Mac OS server?
> 
> Perhaps because the server is not a Mac OS, it doesn't have the uchg
> flag, and maps it to the w bit in the POSIX permission system (this is
> pure speculation from me).
> 
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/
I don’t have any Mac OS X server in my disposal at this moment but if you want to test out with netatalk AFPD I believe it’s available in debian & ubuntu apt repo

Regards, Fairuzan

Junio C Hamano· Feb 17, 2015, 17:13 UTC · re: Matthieu Moy · lore

Re: odb_mkstemp's 0444 permission broke write/delete access on AFP

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
Show 9 quoted lines
> This should be fixable from Git itself, by replacing the calls to
> "unlink" with something like
>
> int unlink_or_chmod(...) {
> 	if (unlink(...)) {
> 		chmod(...); // give user write permission
> 		return unlink(...);
> 	}
> }

I agree with the approach in principle, but I wonder if we want to contaminate the generic codepath with unlink_or_chmod().

Don't we want to have this
	#undef unlink
	int workaround_broken_unlink(...) {
        	... the same ...
	}
in compat/broken-unlink.c and something like this
	#ifdef BROKEN_UNLINK
	#define unlink(x) workaround_broken_unlink(x)
        #endif

in git-compat-util.h instead? That way, people on well behaving systems do not have to worry about clobbering errno and stuff, perhaps?

Matthieu Moy· Feb 18, 2015, 17:04 UTC · re: Junio C Hamano · lore

Re: odb_mkstemp's 0444 permission broke write/delete access on AFP

Junio C Hamano <gitster@pobox.com> writes:
Show 7 quoted lines
> in compat/broken-unlink.c and something like this
>
> 	#ifdef BROKEN_UNLINK
> 	#define unlink(x) workaround_broken_unlink(x)
>         #endif
>
> in git-compat-util.h instead?

That means we have to know BROKEN_UNLINK at compile-time. I had never heard about AFP before this thread, but they seem mountable on Linux and Windows. I don't know whether these platforms will have the same issue, but I suspect they will (if the server rejects the unlink).

So, if my suspicion is right, we'd have to activate it on any platform able to mount AFP, i.e. essentially everywhere.

> That way, people on well behaving systems do not have to worry about
> clobbering errno and stuff, perhaps?

With my solution, unlink() is always the last call in the function, so it should behave correctly right? Or did I miss anything?

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Junio C Hamano· Feb 18, 2015, 17:13 UTC · re: Matthieu Moy · lore

Re: odb_mkstemp's 0444 permission broke write/delete access on AFP

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
Show 17 quoted lines
> Junio C Hamano <gitster@pobox.com> writes:
>
>> in compat/broken-unlink.c and something like this
>>
>> 	#ifdef BROKEN_UNLINK
>> 	#define unlink(x) workaround_broken_unlink(x)
>>         #endif
>>
>> in git-compat-util.h instead? 
>
> That means we have to know BROKEN_UNLINK at compile-time. I had never
> heard about AFP before this thread, but they seem mountable on Linux and
> Windows. I don't know whether these platforms will have the same issue,
> but I suspect they will (if the server rejects the unlink).
>
> So, if my suspicion is right, we'd have to activate it on any platform
> able to mount AFP, i.e. essentially everywhere.
Sigh.
Show 6 quoted lines
>
>> That way, people on well behaving systems do not have to worry about
>> clobbering errno and stuff, perhaps?
>
> With my solution, unlink() is always the last call in the function, so
> it should behave correctly right? Or did I miss anything?

I am primarily worried about blindly attempting to run chmod() after seeing a failure from the first unlink() _without_ even making sure that the failure is caused by this silly bug in a single filesystem.

If the first unlink() failed for some other reason, chmod() succeeded, and then the second unlink() failed for the same reason as the first failure (because the mode bits of the file being unlinked did not have anything to do with it), that would leave a file with wrong permission bits. And doing so when the user may know that there is no AFP involved in her set-up would be doubly wrong, no?

Junio C Hamano· Feb 18, 2015, 17:31 UTC · re: Junio C Hamano · lore

Re: odb_mkstemp's 0444 permission broke write/delete access on AFP

Junio C Hamano <gitster@pobox.com> writes:
Show 21 quoted lines
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> in compat/broken-unlink.c and something like this
>>>
>>> 	#ifdef BROKEN_UNLINK
>>> 	#define unlink(x) workaround_broken_unlink(x)
>>>         #endif
>>>
>>> in git-compat-util.h instead? 
>>
>> That means we have to know BROKEN_UNLINK at compile-time. I had never
>> heard about AFP before this thread, but they seem mountable on Linux and
>> Windows. I don't know whether these platforms will have the same issue,
>> but I suspect they will (if the server rejects the unlink).
>>
>> So, if my suspicion is right, we'd have to activate it on any platform
>> able to mount AFP, i.e. essentially everywhere.
>
> Sigh.
That is "Sigh.  It is unfortunate but you are correct.".
Perhaps we would need to do something ugly like this:
 * add "core.brokenUnlink" configuration (or whatever we end up
   calling this filesystem trait) and add "int broken_unlink" in
   environment.c (declare it in cache.h).
 * in init-db.c, autoprobe by doing something like this:
    create a test file with 0444 permission bits;
    if (unlink(that test file)) {
	chmod(that test file, 0644);
        if (!unlink(that test file)) {
		broken_unlink = 1;
		git_config_set("core.brokenunlink", broken_unlink);
	} else {
        	die("aaargh");
	}
    }
 * Do your unlink_or_chmod() thing in wrapper.c, but perhaps call it
   xunlink(), like this:
        int xunlink(...) {
		int ret = unlink(...);
		if (broken_unlink && ret) {
                        chmod(..., 0644);
                        ret = unlink(...);
                }
                return ret;
        }
We probably need something similar for xrename()?
brian m. carlson· Feb 19, 2015, 20:08 UTC · re: Matthieu Moy · lore

Re: odb_mkstemp's 0444 permission broke write/delete access on AFP

On Tue, Feb 17, 2015 at 09:51:38AM +0100, Matthieu Moy wrote:
Show 14 quoted lines
> This should be fixable from Git itself, by replacing the calls to
> "unlink" with something like
> 
> int unlink_or_chmod(...) {
> 	if (unlink(...)) {
> 		chmod(...); // give user write permission
> 		return unlink(...);
> 	}
> }
> 
> This does not add extra cost in the normal case, and would fix this
> particular issue for afp shares. So, I think that would fix the biggest
> problem for afp-share users without disturbing others. It seems
> reasonable to me to do that unconditionnally.

This can have security issues if you're trying to unlink a symlink, as chmod will dereference the symlink but unlink will not. Giving the file owner write permission may not be sufficient, as the user may be a member of a group with write access to the repo. A malicious user who also has access to the repo could force the current user to chmod an arbitrary file such that it had looser permissions.

I've seen a case where Perl's ExtUtils::MakeMaker chmoded /etc/mime.types 0666 as a result of this.

I don't think there's a secure way to implement this unless you're on an OS with lchmod or fchmodat that supports AT_SYMLINK_NOFOLLOW. Linux is not one of those systems.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
Matthieu Moy· Feb 20, 2015, 10:40 UTC · re: brian m. carlson · lore

Re: odb_mkstemp's 0444 permission broke write/delete access on AFP

"brian m. carlson" <sandals@crustytoothpaste.net> writes:
Show 22 quoted lines
> On Tue, Feb 17, 2015 at 09:51:38AM +0100, Matthieu Moy wrote:
>> This should be fixable from Git itself, by replacing the calls to
>> "unlink" with something like
>> 
>> int unlink_or_chmod(...) {
>> 	if (unlink(...)) {
>> 		chmod(...); // give user write permission
>> 		return unlink(...);
>> 	}
>> }
>> 
>> This does not add extra cost in the normal case, and would fix this
>> particular issue for afp shares. So, I think that would fix the biggest
>> problem for afp-share users without disturbing others. It seems
>> reasonable to me to do that unconditionnally.
>
> This can have security issues if you're trying to unlink a symlink, as 
> chmod will dereference the symlink but unlink will not.  Giving the file 
> owner write permission may not be sufficient, as the user may be a 
> member of a group with write access to the repo.  A malicious user who 
> also has access to the repo could force the current user to chmod an 
> arbitrary file such that it had looser permissions.

Ouch, indeed. I don't think that would be so problematic in practice (if the attacker has access to the repo, it's easier to write arbitrary code in hooks or config), but clearly we don't want to take the risk.

So, the right solution should be stg like Junio's
 * in init-db.c, autoprobe by doing something like this:
    create a test file with 0444 permission bits;
    if (unlink(that test file)) {
	chmod(that test file, 0644);
        if (!unlink(that test file)) {
		broken_unlink = 1;
		git_config_set("core.brokenunlink", broken_unlink);
	} else {
        	die("aaargh");
	}
    }

But when core.brokenunlink is set, just use 0666 instead of 0444 as default mode for object files.

But right now, I'm not sure we're actually to work around an issue with AFP shares or only one particular case of problematic configurtion for one user.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Junio C Hamano· Feb 16, 2015, 19:06 UTC · re: Matthieu Moy · lore

Re: odb_mkstemp's 0444 permission broke write/delete access on AFP

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> The issue is that having object and pack files read-only on the
> filesystem is a safety feature to prevent accidental modifications (even
> though it's actually not that effective, since brute-force "sed -i" or
> "perl -i" still accept to modify read-only files).

I did not see it as a "safety feature", and instead saw it as a reminder to me that I am not supposed to write into them when I check them with "ls -l".

> So, I'd be a bit reluctant to remove this safety feature for all users
> if it's only for the benefit of a minority of users. Not that I think
> the problem shouldn't be fixed, but I'd rather investigate alternate
> solutions before using this mode = 0644.

I fully agree with you that this should not be unconditional. However, I am not sure if there is an effective workaround to a filesystem that pays attention to the mode bits of the file when doing an operation on the directory the file is sitting within. It may be OK to introduce a new configuration variable, perhaps call it core.brokenFileSystemNeedsWritableFile or something, and probe and enable it inside init_db().

But I suspect that the single "mode = 0444" under discussion may not cover all places we create files, as the assumption that the we get a sane semantics from the filesystem permeates throughout the code.

What other glitches does AFP have? Does it share Windows' "you cannot rename a file you have an open file descriptor on?" Anything else?

Torsten Bögershausen· Feb 16, 2015, 19:50 UTC · re: Junio C Hamano · lore

Re: odb_mkstemp's 0444 permission broke write/delete access on AFP

On 16.02.15 20:06, Junio C Hamano wrote:
Show 31 quoted lines
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> 
>> The issue is that having object and pack files read-only on the
>> filesystem is a safety feature to prevent accidental modifications (even
>> though it's actually not that effective, since brute-force "sed -i" or
>> "perl -i" still accept to modify read-only files).
> 
> I did not see it as a "safety feature", and instead saw it as a
> reminder to me that I am not supposed to write into them when I
> check them with "ls -l".
> 
>> So, I'd be a bit reluctant to remove this safety feature for all users
>> if it's only for the benefit of a minority of users. Not that I think
>> the problem shouldn't be fixed, but I'd rather investigate alternate
>> solutions before using this mode = 0644.
> 
> I fully agree with you that this should not be unconditional.
> However, I am not sure if there is an effective workaround to a
> filesystem that pays attention to the mode bits of the file when
> doing an operation on the directory the file is sitting within.  It
> may be OK to introduce a new configuration variable, perhaps call it
> core.brokenFileSystemNeedsWritableFile or something, and probe and
> enable it inside init_db().
> 
> But I suspect that the single "mode = 0444" under discussion may not
> cover all places we create files, as the assumption that the we get
> a sane semantics from the filesystem permeates throughout the code.
> 
> What other glitches does AFP have?  Does it share Windows' "you
> cannot rename a file you have an open file descriptor on?"  Anything
> else?
May I ask which OS you have on the server side, and which on the client side?

I'm aware that Mac OS "speaks" AFP, but even Linux can do and there is SW which enables AFP on a Windows machine (all this is server side).

As a client we may have Mac OS, Linux (not sure if Windows can use APF) What do you use ?

← back to recent threads