Re: fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |

[Zenobiusz Kunegunda <zenobiusz.kunegunda@interia.pl>]

Od: "René Scharfe" <l.s.r@web.de>
Do: "Stefan Beller" <sbeller@google.com>; 
Wysłane: 22:08 Piątek 2017-03-17
Temat: Re: fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |

> 
>> Am 17.03.2017 um 20:45 schrieb Stefan Beller:
>> On Fri, Mar 17, 2017 at 12:34 PM, René Scharfe  wrote:
>>> Am 15.03.2017 um 22:30 schrieb René Scharfe:
>>>> Am 15.03.2017 um 10:44 schrieb Zenobiusz Kunegunda:
>>>>> $ git bisect bad
>>>>> 7333ed1788b4f2b162a35003044d77a716732a1f is the first bad commit
>>>>> commit 7333ed1788b4f2b162a35003044d77a716732a1f
>>>>> Author: René Scharfe 
>>>>> Date:   Mon Jul 28 20:26:40 2014 +0200
>>>>>
>>>>>     setup: convert setup_git_directory_gently_1 et al. to strbuf
>>>>
>>>> That's what I half-suspected, and I think by now I got an idea.  Here's
>>>> a test program:
>>>
>>> And here's a patch for letting strbuf_getcwd() use the same getcwd(3)
>>> extension that pwd(1) uses.  It avoids the need to guess the path's
>>> length and thus reduces the chance of stumbling over strange error
>>> codes.  I wonder if it helps in your case.
>>>
>>> René
>>>
>>> ---
>>>  strbuf.c | 8 ++++++++
>>>  1 file changed, 8 insertions(+)
>>>
>>> diff --git a/strbuf.c b/strbuf.c
>>> index ace58e7367..4c02801edd 100644
>>> --- a/strbuf.c
>>> +++ b/strbuf.c
>>> @@ -442,6 +442,14 @@ int strbuf_getcwd(struct strbuf *sb)
>>>  {
>>>         size_t oldalloc = sb->alloc;
>>>         size_t guessed_len = 128;
>>> +       char *cwd;
>>> +
>>> +       cwd = getcwd(NULL, 0);
>>
>> from my local man pages:
>>
>>   As  an extension to the POSIX.1-2001 standard, Linux (libc4, libc5,
>> glibc) getcwd()
>>   allocates the buffer dynamically using malloc(3) if buf is NULL.  In
>> this case, the
>>   allocated buffer has the length size unless size is zero, when buf
>> is allocated as big
>>   as necessary.  The caller should free(3) the returned buffer.
>>
>> This sounds specific to Linux (though I am reading Linux man pages,
>> which claim this; Also it seems I might have misread it as it also states
>> "The pathname is returned as the function result and via the
>> argument buf, if present.").
> 
> I'm only interested in FreeBSD for now, as that's the platform Zenobiusz 
> reported the issue on and I haven't been able to reproduce it, so this 
> is still a bit exploratory, but hopefully getting closer.  This 
> extension is used in the first version of pwd(1) in FreeBSD's repo, 
> comitted 1994-05-26, so it was supported there basically forever.
> 
> The oldest version I found that's using the extention is NetBSD's 
> pwd(1), which was committed 1993-03-21 and carries a SCCS timestamp of 
> 1991-02-20.  Visual Studio .NET 2003 supports it as well.
> 
>> Looking further:
>>
>>   These functions are often used to save the location of the current
>>   working directory for the purpose of returning to it later.  Opening the
>>   current directory (".")  and  calling  fchdir(2)  to return is
>> usually a faster
>>   and more reliable alternative when sufficiently many file descriptors are
>>   available, especially on platforms other than Linux.
>>
>> Not sure if that opens another door here?
> 
> Reducing the use of absolute paths may be a good idea in general, but 
> that would probably require major changes.  And Windows doesn't seem to 
> offer fchdir() at all; I don't know if it has an equivalent function 
> that could be used to build a replacement.
> 
> René
> 
> 

I think I found a way to reproduce this error.
I installed FreeBSD 10.3 under qemu with zfs partitioning.
Test program did not report any access errors.
Then I did chmod 711 /usr/home
Now program started reporting permission denied errors just like this:
   $ ./a.out  
   len = 0, errno = 22, Invalid argument
   len = 1, errno = 34, Result too large
   len = 2, errno = 13, Permission denied
   len = 20, errno = 0, No error: 0