Re: permissions

[William Pursell <bill.pursell@gmail.com>]

Alex Riesen wrote:
> On Wed, Jun 9, 2010 at 00:27, William Pursell <bill.pursell@gmail.com> wrote:
>> Junio C Hamano wrote:
>>> Alex Riesen <raa.lkml@gmail.com> writes:
>>>
>>>> On Tue, Jun 8, 2010 at 12:25, William Pursell <bill.pursell@gmail.com> wrote:
>>>>> Here's a patch.  This doesn't address the issue of a damaged
>>>>> repository, but just catches access errors and permissions.
>>>> The change looks fishy.
>>>>
>>>> The patch moves the function is_git_directory at the level of user
>>>> interface where it wasn't before: it now complains and die.
>>>> Not all callers of the function call it only to die if it fails.
>>> Thanks for shooting it down before I had to look at it ;-)
>> The point of the patch is that it now complains and dies.
> 
> At wrong point. Points, actually. There are many callers of the
> function you modified. You should have looked at them all.

I did look at all 4 calls, and it seemed to me
that localizing the change in one location is a better
design than adding logic to 4 different locations.

>> Perhaps I'm being obtuse, but can you describe a situation
>> in which this causes git to terminate inappropriately?
> 
> Maybe. BTW, can you? (if you try, I mean).

No, I can't.  As far as I can tell, the patch adds
exactly the functionality that I want it to add.  You
do make good points about its problems below, however,
and you are right that I did miss the point of
your criticism.  Thank you for clarifying.

> But your questions
> misses the point of my complaint about your patch:
> 
> The patch makes the function you modified act not as one
> can guess from its other uses. Imagine someone replaced
> open(2) implementation to kill your program everytime you
> tried to open /etc/passwd. How'd you like that?

I think there is a substantial difference between changing
a basic library call and changing a statically linked
function called from only 4 locations, but I'll agree
that you have a valid point about the function not
behaving as expected.  The functionality I've added disagrees
with the name of the function, so on that point alone I will
agree that the patch is no good.

> 
> That alone is reason enough to dislike the change and put
> you personally into a list of persons to be careful with (as
> you don't seem to care about what happens with the code
> after you changed it).

I do care quite a lot actually.  My primary goal
was to minimize the changes, and it seemed that
is_git_directory() was the right place to make
the change with minimal impact.  Perhaps the following
patch would be more to your liking:


diff --git a/setup.c b/setup.c
index 7e04602..b25da21 100644
--- a/setup.c
+++ b/setup.c
@@ -303,6 +303,9 @@ const char *read_gitfile_gently(const char *path)
 		buf = dir;
 	}

+	if (access(dir, X_OK))
+		die_errno("Unable to access %s", dir);
+
 	if (!is_git_directory(dir))
 		die("Not a git repository: %s", dir);
 	path = make_absolute_path(dir);
@@ -370,6 +373,9 @@ const char *setup_git_directory_gently(int *nongit_ok)
 			*nongit_ok = 1;
 			return NULL;
 		}
+		if (access(gitdirenv, X_OK))
+			die_errno("Unable to access %s", gitdirenv);
+
 		die("Not a git repository: '%s'", gitdirenv);
 	}

@@ -407,6 +413,11 @@ const char *setup_git_directory_gently(int *nongit_ok)
 		}
 		if (is_git_directory(DEFAULT_GIT_DIR_ENVIRONMENT))
 			break;
+		if (access(DEFAULT_GIT_DIR_ENVIRONMENT, X_OK)
+				 && errno != ENOENT )
+			die_errno("Unable to access %s/%s",
+				 cwd, DEFAULT_GIT_DIR_ENVIRONMENT);
+
 		if (is_git_directory(".")) {
 			inside_git_dir = 1;
 			if (!work_tree_env)
diff --git a/t/t0002-gitfile.sh b/t/t0002-gitfile.sh
index cb14425..9f6f756 100755
--- a/t/t0002-gitfile.sh
+++ b/t/t0002-gitfile.sh
@@ -46,7 +46,7 @@ test_expect_success 'bad setup: invalid .git file path' '
 		echo "git rev-parse accepted an invalid .git file path"
 		false
 	fi &&
-	if ! grep "Not a git repository" .err
+	if ! grep "Unable to access $REAL.not" .err
 	then
 		echo "git rev-parse returned wrong error"
 		false

-- 
William Pursell