get git not to care about permissions

get git not to care about permissions

[sconeman]

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.

Re: get git not to care about permissions

[Jay Soffian]

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.

Re: get git not to care about permissions

[Eugene Sajine]

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

Re: get git not to care about permissions

[Matt Schoen]

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

Re: get git not to care about permissions

[Matt Schoen]

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

Re: get git not to care about permissions

[Thomas Rast]

Matt Schoen wrote:
> 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

Re: get git not to care about permissions

[Matt Schoen]

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.

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

Re: get git not to care about permissions

[Thomas Rast]

Matt Schoen wrote:
> 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