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

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

[Fairuzan Roslan]

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

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

[Matthieu Moy]

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/

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

[Fairuzan Roslan]

[-- Attachment #1: Type: text/plain, Size: 2114 bytes --]

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


> 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/


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

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

[Junio C Hamano]

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?

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

[Matthieu Moy]

[ 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/

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

[Torsten Bögershausen]

On 16.02.15 20:06, Junio C Hamano wrote:
> 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 ?

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

[Fairuzan Roslan]

[-- Attachment #1: Type: text/plain, Size: 4783 bytes --]


> 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






[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

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

[Torsten Bögershausen]

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 ?

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

[Fairuzan Roslan]

[-- Attachment #1: Type: text/plain, Size: 4948 bytes --]


> 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


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

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

[Matthieu Moy]

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/

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

[Fairuzan Roslan]

[-- Attachment #1: Type: text/plain, Size: 4045 bytes --]


> 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



[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

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

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> 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?

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

[Torsten Bögershausen]

On 17/02/15 17:58, Fairuzan Roslan wrote:
> 
>> 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)

> $ 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.
> 
> 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.







 

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

[Matthieu Moy]

Torsten Bögershausen <tboegi@web.de> writes:

> 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/

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

[Fairuzan Roslan]

[-- Attachment #1: Type: text/plain, Size: 1947 bytes --]


> 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


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

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

[Matthieu Moy]

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/

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

[Fairuzan Roslan]

[-- Attachment #1: Type: text/plain, Size: 824 bytes --]


> 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

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

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

[Matthieu Moy]

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.

> 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/

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

[Junio C Hamano]

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 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?

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

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> 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()?
	

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

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1481 bytes --]

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.

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Matthieu Moy]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> 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/