threads / discuss / 21544

get git not to care about permissions

Subject: get git not to care about permissions

## tl;dr

8 messages between Nov 9, 2009 and Nov 15, 2009.

replies: 7people: 5as markdown or json

sconeman· Nov 9, 2009, 16:06 UTC · lore
Hello,

I'm trying to set up git on a NetApp drive at my school, BU. The NetApp shares are configured with Windows permissions, and I forget the specifics (which I can figure out if needed) about why this is the case, but basically the deal is that if true UNIX permissions were to be used, Windows wouldn't be able to read the drive. As such, and because we use the Kerberos ticketing system, the permissions for the drive are set up such that the owners (myself and my team members) have full permissions, but nobody else does. Git doesn't like this and won't even create a bare repository. Is there any way I can get git to ignore permissions and just do what it needs to do?

Thanks in advance for the help!
-Matt
-- 
View this message in context: http://old.nabble.com/get-git-not-to-care-about-permissions-tp26268938p26268938.html
Sent from the git mailing list archive at Nabble.com.
Jay Soffian· Nov 12, 2009, 05:44 UTC · re: sconeman · lore

Re: get git not to care about permissions

On Wed, Nov 11, 2009 at 4:17 PM, sconeman <schoen@bu.edu> wrote:
> does.  Git doesn't like this and won't even create a bare repository.  Is
> there any way I can get git to ignore permissions and just do what it needs
> to do?
And the output from "git init --bare" is?
j.
Matt Schoen· Nov 12, 2009, 15:44 UTC · re: Jay Soffian · lore

Re: get git not to care about permissions

The only output I get is:

warning: templates not found /tmp/git/share/git-core/templates error: Unable to open /ad/eng/courses/ec/ec464/ec464-team03/test.git/HEAD.lock for writing

ls -al in the directory gives me: total 12 drwx------ 3 schoen root 4096 Nov 12 10:41 . d--------- 7 root root 4096 Nov 12 10:41 .. -rwx------ 1 schoen root 0 Nov 12 10:41 HEAD.lock drwx------ 4 schoen root 4096 Nov 12 10:41 refs

As I understand it, because we use Kerberos, permissions on everything must be set to 700 at most. I think the issue here comes from the fact that git wants to use group permissions. This is my guess.

On Thu, Nov 12, 2009 at 12:44 AM, Jay Soffian <jaysoffian@gmail.com> wrote:
Show 10 quoted lines
> On Wed, Nov 11, 2009 at 4:17 PM, sconeman <schoen@bu.edu> wrote:
>> does.  Git doesn't like this and won't even create a bare repository.  Is
>> there any way I can get git to ignore permissions and just do what it needs
>> to do?
>
> And the output from "git init --bare" is?
>
> j.
>
>
Thomas Rast· Nov 12, 2009, 16:10 UTC · re: Matt Schoen · lore

Re: get git not to care about permissions

Matt Schoen wrote:
Show 8 quoted lines
> error: Unable to open
> /ad/eng/courses/ec/ec464/ec464-team03/test.git/HEAD.lock for writing
> 
> ls -al in the directory gives me:
> total 12
> drwx------ 3 schoen root 4096 Nov 12 10:41 .
> d--------- 7 root   root 4096 Nov 12 10:41 ..
> -rwx------ 1 schoen root    0 Nov 12 10:41 HEAD.lock
At least in my current copy, this can only come from
	// lock.c:1371
	lockpath = mkpath("%s.lock", git_HEAD);
	fd = open(lockpath, O_CREAT | O_EXCL | O_WRONLY, 0666);
	if (fd < 0) {
		error("Unable to open %s for writing", lockpath);

It prints an absolute path, so the open() also accesses an absolute path (though I don't know why it insists on that).

But the above directory listing would indicate that you do not even have permission to look inside your $(pwd) by absolute path...

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
Matt Schoen· Nov 12, 2009, 21:44 UTC · re: Thomas Rast · lore

Re: get git not to care about permissions

On Thu, Nov 12, 2009 at 11:10 AM, Thomas Rast <trast@student.ethz.ch> wrote:
Show 5 quoted lines
> It prints an absolute path, so the open() also accesses an absolute
> path (though I don't know why it insists on that).
>
> But the above directory listing would indicate that you do not even
> have permission to look inside your $(pwd) by absolute path...

I'm pretty sure I can. How can I test this? I can ls all subdirectories within the path, and when I navigate to the path, I usually do it absolutely. After all, this is a network share, so I have to start with "/ad/eng/...". Although, this is curious. Some of the directories show "d---------" when I do ls -al. They were created by root in the same environment (forced 700), but I can still read their contents, and such.

Does open() strictly require the permissions you give it? Like I mentioned, the permissions are locked at 700. Even if I try to chmod 777 the directory, I see no error, but the permissions remain unchanged. I'm thinking of doing a custom compile, removing those places where specific permissions are needed. My fear is that those places are many...

Thomas Rast· Nov 15, 2009, 12:31 UTC · re: Matt Schoen · lore

Re: get git not to care about permissions

Matt Schoen wrote:
Show 14 quoted lines
> On Thu, Nov 12, 2009 at 11:10 AM, Thomas Rast <trast@student.ethz.ch> wrote:
> > It prints an absolute path, so the open() also accesses an absolute
> > path (though I don't know why it insists on that).
> >
> > But the above directory listing would indicate that you do not even
> > have permission to look inside your $(pwd) by absolute path...
> 
> I'm pretty sure I can.  How can I test this?  I can ls all
> subdirectories within the path, and when I navigate to the path, I
> usually do it absolutely.  After all, this is a network share, so I
> have to start with "/ad/eng/...".  Although, this is curious.  Some of
> the directories show "d---------" when I do ls -al.  They were created
> by root in the same environment (forced 700), but I can still read
> their contents, and such.

What filesystem is this? Are there perhaps extended attributes allowing access anyway? I'm not exactly an expert on unix permissions but my local path_resolution(7) tells me it should not be possible to cd beyond a directory where you have no 'x' permissions.

> Does open() strictly require the permissions you give it?

open(2) says the permissions are modified by the umask, so that shouldn't be a problem.

Question for the people who know git better than me: Does that open() require an absolute path?

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
Eugene Sajine· Nov 12, 2009, 15:28 UTC · lore

Re: get git not to care about permissions

Show 21 quoted lines
>>
>> On Nov 9, 2009 11:06 AM, "sconeman" <schoen@bu.edu> wrote:
>>
>>
>> Hello,
>>
>> I'm trying to set up git on a NetApp drive at my school, BU.  The NetApp
>> shares are configured with Windows permissions, and I forget the specifics
>> (which I can figure out if needed) about why this is the case, but basically
>> the deal is that if true UNIX permissions were to be used, Windows wouldn't
>> be able to read the drive.  As such, and because we use the Kerberos
>> ticketing system, the permissions for the drive are set up such that the
>> owners (myself and my team members) have full permissions, but nobody else
>> does.  Git doesn't like this and won't even create a bare repository.  Is
>> there any way I can get git to ignore permissions and just do what it needs
>> to do?
>>
>> Thanks in advance for the help!
>>
>> -Matt
> --
On Wed, Nov 11, 2009 at 4:34 PM, Eugene Sajine <euguess@gmail.com> wrote:
Show 10 quoted lines
> Hi,
>
> I had almost similar issue - bare repos in my case should be set up under
> user which only few guys are having password from. So what I did is just a
> small program which creates the bare repo locally and makes secure copy to
> this user home. All authentication is hidden from the end user. Then users
> can access their repos via git protocol. Ialso fillthe repo with some
> additional info for cgit.
>
> Eugene

BTW I'm using "git clone --bare" in this process, so if you have a repo with working copy you can create a bare one separately, put it on the server and then connect to it via "git remote add"

Eugene
Matt Schoen· Nov 12, 2009, 15:47 UTC · re: Eugene Sajine · lore

Re: get git not to care about permissions

Thanks for the tip, Eugene, but I'm not sure if this helps me.

I'm trying to set up the repo on a shared directory, which isn't actually on a physical computer (NetApp is basically a data-server-in-a-box, and as such I do not directly interface with it). Thus, I must access the directory over the school network, which uses Kerberos security. I think it is this restriction that is giving git its issues.

On Thu, Nov 12, 2009 at 10:28 AM, Eugene Sajine <euguess@gmail.com> wrote:
Show 40 quoted lines
>>>
>>> On Nov 9, 2009 11:06 AM, "sconeman" <schoen@bu.edu> wrote:
>>>
>>>
>>> Hello,
>>>
>>> I'm trying to set up git on a NetApp drive at my school, BU.  The NetApp
>>> shares are configured with Windows permissions, and I forget the specifics
>>> (which I can figure out if needed) about why this is the case, but basically
>>> the deal is that if true UNIX permissions were to be used, Windows wouldn't
>>> be able to read the drive.  As such, and because we use the Kerberos
>>> ticketing system, the permissions for the drive are set up such that the
>>> owners (myself and my team members) have full permissions, but nobody else
>>> does.  Git doesn't like this and won't even create a bare repository.  Is
>>> there any way I can get git to ignore permissions and just do what it needs
>>> to do?
>>>
>>> Thanks in advance for the help!
>>>
>>> -Matt
>> --
> On Wed, Nov 11, 2009 at 4:34 PM, Eugene Sajine <euguess@gmail.com> wrote:
>> Hi,
>>
>> I had almost similar issue - bare repos in my case should be set up under
>> user which only few guys are having password from. So what I did is just a
>> small program which creates the bare repo locally and makes secure copy to
>> this user home. All authentication is hidden from the end user. Then users
>> can access their repos via git protocol. Ialso fillthe repo with some
>> additional info for cgit.
>>
>> Eugene
>
> BTW I'm using "git clone --bare" in this process, so if you have a
> repo with working copy you can create a bare one separately, put it on
> the server and then connect to it via "git remote add"
>
> Eugene
>
>

← back to recent threads