threads / discuss / 22180

[RFH] Git and filesystem ACLs: problem with 'git gc'

Subject: [RFH] Git and filesystem ACLs: problem with 'git gc'

## tl;dr

2 messages between Jan 12, 2010 and Jan 13, 2010.

replies: 1people: 1as markdown or json

Matthieu Moy· Jan 12, 2010, 13:57 UTC · lore
Hi,

I tried setting up a Git repository restricting the access using the filesystem's ACL. In short: It almost works, but pack creation break it. I'm looking for help to fix it.

The setup is: my user is "moy", my $HOME is rwx------ and my umask is 077 (i.e. by default, I don't share anything). I want to authorize a user "foo" to access my repository:

cd ~/test/ git init testacl setfacl -Rm u:foo:rwx '/home/moy/test/testacl' setfacl -Rm d:u:foo:rwx '/home/moy/test/testacl' setfacl -Rm d:u:moy:rwx '/home/moy/test/testacl' setfacl -m u:foo:x '/home/moy/test' setfacl -m u:foo:x '/home/moy'

With this setup, I can create new files, and the user foo can do the same, the ACLs give permission to each other. Object creation (git add, git commit) work:

$ getfacl .git/objects/3c/7a37f109f8e7f7b9f8b64833ea331fa9b047f5 # file: .git/objects/3c/7a37f109f8e7f7b9f8b64833ea331fa9b047f5 # owner: moy # group: perms user::r-- user:moy:rwx user:foo:rwx group::--- mask::rwx other::r--

but when pack files are created by a user, the file is not readable by the other:

$ getfacl .git/objects/pack/pack-cf224e8b0da92fd72fbea8f101912db4835445d1.pack # file: .git/objects/pack/pack-cf224e8b0da92fd72fbea8f101912db4835445d1.pack # owner: moy # group: perms user::r-- user:moy:rwx #effective:--- user:len:rwx #effective:--- group::--- mask::--- other::---

$ ls -l .git/objects/pack/pack-cf224e8b0da92fd72fbea8f101912db4835445d1.pack -r--------+ 1 moy perms 468 Jan 12 13:18 .git/objects/pack/pack-cf224e8b0da92fd72fbea8f101912db4835445d1.pack

My interpretation of the problem is that Git tried to remove the permission for group (~ chmod g-rwx) on the pack file, and as an undesirable side effect, setting the group permissions also sets the ACL mask, and prevents other users from accessing it, even though they have a user-ACL.

A workaround for this is to set core.sharedrepository to 'group', but since object creation just works, I guess the pack creation should just work too, with or without core.sharedrepository ...

I investigated a bit, and the problem seems to come from mkstemp, which is used by write_pack_file to create the temporary file: files created by mkstemp get an ACL umask of ---.

Is it really a good idea to use mkstemp? We're inside .git/object/pack, for which the user is supposed to have already set correct permissions, so shouldn't we just create a random file name and then use a plain open(...) to create the file, leaving the umask do its job to control the permissions?

Thanks,

-- Matthieu Moy http://www-verimag.imag.fr/~moy/

Matthieu Moy· Jan 13, 2010, 14:56 UTC · re: Matthieu Moy · lore

Re: [RFH] Git and filesystem ACLs: problem with 'git gc'

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
Show 9 quoted lines
> I investigated a bit, and the problem seems to come from mkstemp,
> which is used by write_pack_file to create the temporary file: files
> created by mkstemp get an ACL umask of ---.
>
> Is it really a good idea to use mkstemp? We're inside
> .git/object/pack, for which the user is supposed to have already set
> correct permissions, so shouldn't we just create a random file name
> and then use a plain open(...) to create the file, leaving the umask
> do its job to control the permissions?
Digging a bit further, I noticed that _object_ creation was doing a
  set_shared_perm(filename, (S_IFREG|0444))

thus ignoring the umask, and setting r--r--r-- for all objects, while _pack_ creation does roughly (in write_pack_file()) :

  mode_t mode = umask(0);
  mode = 0444 & ~mode;
  adjust_perm(pack_tmp_name, mode)

Thus setting the permissions to r--X--X-- where X is defined by the umask. Is there any reason for this difference? I'd say we can rely on the containing directory's permissions, and do for pack what Git already does for objects.

[ On a side note, I don't understand what the S_IFREG is doing in the call to set_shared_perm. It's passed to chmod, while S_IFREG is only documented in the manpage for stat() ... ]

Thanks,
-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

← back to recent threads