threads / discuss / 2887
Subject: git /objects directory created 755 by default?
Martin LanghoffJunio,
Since git changed to creating the objects subdirectories "on demand", these are created 755 regardless of the user's umask. This is quite inconvenient in ("cvs style") team-shared repositories, which work great otherwise.
Didn't find any relevant discussion in the archives... I am not sure if this is by design. In any case it is something we could work around with a post-update hook on the server side (and I'd be happy to document).
cheers,
martin
Junio C HamanoRe: git /objects directory created 755 by default?
Martin Langhoff <martin.langhoff@gmail.com> writes:
> Since git changed to creating the objects subdirectories "on demand",
> these are created 755 regardless of the user's umask. This is quite
> inconvenient in ("cvs style") team-shared repositories, which work
> great otherwise.Hmph.
I have 002 as umask. .git/objects or .git/objects/[0-9a-f]{2} directories are created 0775 for me.
Do we have hardcoded 0755 that we need to change to 0777 somewhere? sha1_file.c::safe_create_leading_directories() is the primary code that creates directories lazily, and we mkdir with 0777 there.
Junio C HamanoRe: git /objects directory created 755 by default?
Junio C Hamano <junkio@cox.net> writes:
> Martin Langhoff <martin.langhoff@gmail.com> writes:
>
>> Since git changed to creating the objects subdirectories "on demand",
>> these are created 755 regardless of the user's umask. This is quite
>> inconvenient in ("cvs style") team-shared repositories, which work
>> great otherwise.
>
> Hmph.
>
> I have 002 as umask. .git/objects or .git/objects/[0-9a-f]{2}
> directories are created 0775 for me.Martin, is this happening when your developers push into the shared repo? If so, do your developers use git-shell? Do their umask set properly even when they come over ssh and gets into noninteractive shell? What do they see when they do this?
$ ssh shared.repo.machine.example.com umask
the answer may wall be "What do you think I am, A shell?", or 0022.
The git-shell command is designed to be not git aware (it does not know how a git repository looks like, nor does not know all the commands it can handle right now happen to take the repository directory as their first parameter). If we do not mind butchering things, we could introduce:
[shell]
umask = 0002to the configuration file, and do something like this (not even compile tested, and I am not sure what else it breaks):
---
diff --git a/shell.c b/shell.c index cd31618..33898f8 100644 --- a/shell.c +++ b/shell.c @@ -1,15 +1,34 @@ #include "cache.h" #include "quote.h" -static int do_generic_cmd(const char *me, char *arg) +static int shell_umask = 0002; /* default */ + +static int slurp_repository_umask(const char *var, const char *value) +{ + if (!strcmp(var, "shell.umask")) + shell_umask = git_config_int(value); + else + return git_default_config(var, value); + return 0; +} + +/* + * These commands take arg == git repository directory. + */ +static int do_git_repo_cmd(const char *me, char *arg) { const char *my_argv[4]; if (!arg || !(arg = sq_dequote(arg))) die("bad argument"); + if (!enter_repo(arg, 0)) + die("'%s': Nah -- not a git repository", arg); + git_config(slurp_repository_umask); + umask(shell_umask); + my_argv[0] = me; - my_argv[1] = arg; + my_argv[1] = "."; my_argv[2] = NULL; return execvp(me, (char**) my_argv); @@ -19,8 +38,8 @@ static struct commands { const char *name; int (*exec)(const char *me, char *arg); } cmd_list[] = { - { "git-receive-pack", do_generic_cmd }, - { "git-upload-pack", do_generic_cmd }, + { "git-receive-pack", do_git_repo_cmd }, + { "git-upload-pack", do_git_repo_cmd }, { NULL }, };
Martin LanghoffRe: git /objects directory created 755 by default?
On 12/21/05, Junio C Hamano <junkio@cox.net> wrote:
> Martin, is this happening when your developers push into the > shared repo?
yes...
> If so, do your developers use git-shell?
no...
> Do their > umask set properly even when they come over ssh and gets into > noninteractive shell?
Oh DUH. PEBKAK. .bash_profile != .bashrc
I think I owe you an apology and a couple of beers -- I'm an idiot. No wonder I feel "at home" with "git"...
cheers,
martin
Junio C HamanoRe: git /objects directory created 755 by default?
Martin Langhoff <martin.langhoff@gmail.com> writes:
> I think I owe you an apology and a couple of beers...
Nah, you do not owe me anything. Does something like this look good?
-- >8 -- [PATCH] A shared repository should be writable by members.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt index 1683f0b..1b85cab 100644 --- a/Documentation/tutorial.txt +++ b/Documentation/tutorial.txt @@ -1625,7 +1625,9 @@ cooperation you are probably more famili For this, set up a public repository on a machine that is reachable via SSH by people with "commit privileges". Put the committers in the same user group and make the repository -writable by that group. +writable by that group. Make sure their umasks are set up to +allow group members to write into directories other members +have created. You, as an individual committer, then:
Martin LanghoffRe: git /objects directory created 755 by default?
On 12/21/05, Junio C Hamano <junkio@cox.net> wrote:
> Martin Langhoff <martin.langhoff@gmail.com> writes: > > > I think I owe you an apology and a couple of beers... > > Nah, you do not owe me anything. Does something like this look > good?
Yup, makes sense to me. I often explain it as "same file permissions and access model as you'd use with CVS".
cheers,
martin
Junio C HamanoRe: git /objects directory created 755 by default?
Martin Langhoff <martin.langhoff@gmail.com> writes:
>> If so, do your developers use git-shell? > > no...
While we established that your problem did not have anything to do with git-shell, I am tempted to do something like this.
Thoughts?
-- >8 -- [PATCH] Force group writable umask in git-shell
Usually I do not like hardcoded policy in programs, but use of git-shell is already a policy decision by the repository administrator to use the shared repository style of development, and I cannot think of a reason to forbid group (and self, but that is obvious) writability in such use scenario.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/shell.c b/shell.c index cd31618..40a2a97 100644 --- a/shell.c +++ b/shell.c @@ -52,6 +52,10 @@ int main(int argc, char **argv) default: continue; } + /* Make sure myself and my group members can write + * into what I create. + */ + umask(umask(0) & ~0770); exit(cmd->exec(cmd->name, arg)); } die("unrecognized command '%s'", prog);
Martin LanghoffRe: git /objects directory created 755 by default?
On 12/21/05, Junio C Hamano <junkio@cox.net> wrote:
> [PATCH] Force group writable umask in git-shell > > Usually I do not like hardcoded policy in programs, but use of > git-shell is already a policy decision by the repository > administrator to use the shared repository style of development, > and I cannot think of a reason to forbid group (and self, but > that is obvious) writability in such use scenario.
Could git-shell also be used by a SourceForge-like project, offering per-developer git repositories? If they are using the (BSDish?) convention of not having a group per user this could backfire.
Does any unix these days _not_ use a group per user?
cheers,
martin
Junio C HamanoRe: git /objects directory created 755 by default?
Martin Langhoff <martin.langhoff@gmail.com> writes:
> Could git-shell also be used by a SourceForge-like project, offering > per-developer git repositories? If they are using the (BSDish?) > convention of not having a group per user this could backfire.
Fair enough. And I realize that the initial umask should be configurable by the administrator who prepares ssh accounts somehow (I do not know exactly how though).
Martin LanghoffRe: git /objects directory created 755 by default?
On 12/21/05, Junio C Hamano <junkio@cox.net> wrote:
> Martin Langhoff <martin.langhoff@gmail.com> writes: > > > Could git-shell also be used by a SourceForge-like project, offering > > per-developer git repositories? If they are using the (BSDish?) > > convention of not having a group per user this could backfire. > > Fair enough. And I realize that the initial umask should be > configurable by the administrator who prepares ssh accounts > somehow (I do not know exactly how though).
Something like rssh, which supports rsync, cvs and sftp (and should support git!), can set the umask based on a config. I think /etc/bashrc would work too. In Eduforge, I think we have /etc/skel with a group-friendly umask.
cheers,
martin
Ben CliffordRe: git /objects directory created 755 by default?
> Could git-shell also be used by a SourceForge-like project, offering > per-developer git repositories? If they are using the (BSDish?) > convention of not having a group per user this could backfire. > > Does any unix these days _not_ use a group per user?
At least two reasonably sized shops that I have worked with previously do not have group-per-user (and I think two others but I cannot remember about those) - they have centrally administered user accounts and just have groups like 'i am in department X', or 'I am allowed to write into $SOMEPROJECT cvs'.
But that's not a per-unix decision, its a per-organisation administrative decision.
In any case, their usage of groups wrt shared CVS would not have a problem with a 77x mask, though there might be problems (I haven't thought about it enough) with the setgid(?) bit on directories - we used to hit this occasionally in CVS when a directory would end up being created with a user's primary group rather than the 'I am allowed to write into CVS' group. There is too much wine in me at the moment to work out if its also a problem for git...
Johannes SchindelinRe: git /objects directory created 755 by default?
Hi,
On Tue, 20 Dec 2005, Junio C Hamano wrote:
> [shell] > umask = 0002
If you don't use git-shell, because the same machine is used for other purposes, it makes sense to introduce
[core] umask = 0002
How about this:
--- [PATCH] Introduce core.umask
This makes it possible to setup a shared git repository by setting
[core] umask = 0002
int the template config file.
This patch makes sure even git-init-db uses it.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
init-db.c | 21 ++++++++++++++------- setup.c | 4 ++++ 2 files changed, 18 insertions(+), 7 deletions(-)
faa7d4b101211ac1993d73bb3d02e8a6d2c40734
diff --git a/init-db.c b/init-db.c index 41576bd..26812ce 100644 --- a/init-db.c +++ b/init-db.c @@ -164,6 +164,7 @@ static void create_default_files(const c unsigned char sha1[20]; struct stat st1; char repo_version_string[10]; + mode_t mask, mask2; if (len > sizeof(path)-50) die("insane git directory %s", git_dir); @@ -172,6 +173,19 @@ static void create_default_files(const c if (len && path[len-1] != '/') path[len++] = '/'; + /* First copy the templates -- we might have the default + * config file there, in which case we would want to read + * from it after installing. + * The config file may contain a umask... + */ + path[len] = 0; + umask(mask = umask(0)); + copy_templates(path, len, template_path); + if (mask != (mask2 = umask(mask))) { + umask(mask2); + chmod(path, 0777 & ~mask2); + } + /* * Create .git/refs/{heads,tags} */ @@ -182,13 +196,6 @@ static void create_default_files(const c strcpy(path + len, "refs/tags"); safe_create_dir(path); - /* First copy the templates -- we might have the default - * config file there, in which case we would want to read - * from it after installing. - */ - path[len] = 0; - copy_templates(path, len, template_path); - git_config(git_default_config); /* diff --git a/setup.c b/setup.c index d3556ed..4e4cb46 100644 --- a/setup.c +++ b/setup.c @@ -180,6 +180,10 @@ int check_repository_format_version(cons { if (strcmp(var, "core.repositoryformatversion") == 0) repository_format_version = git_config_int(var, value); + + else if (!strcmp(var, "core.umask")) + umask(git_config_int(var, value)); + return 0; }
-- 1.0.0
Junio C HamanoRe: git /objects directory created 755 by default?
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> If you don't use git-shell, because the same machine is used for other > purposes, it makes sense to introduce > > [core] > umask = 0002
I agree the setting should not be limited to git-shell, but I do not think setting "umask" from git configuration is the right way either. For files and directories under $GIT_DIR, maybe imposing the policy git configuration file has is OK, but I think honoring the user's umask is the right thing for working tree files.
Johannes SchindelinRe: git /objects directory created 755 by default?
Hi,
On Wed, 21 Dec 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > > If you don't use git-shell, because the same machine is used for other > > purposes, it makes sense to introduce > > > > [core] > > umask = 0002 > > I agree the setting should not be limited to git-shell, but I do > not think setting "umask" from git configuration is the right > way either. For files and directories under $GIT_DIR, maybe > imposing the policy git configuration file has is OK, but I > think honoring the user's umask is the right thing for working > tree files.
As we worked out in another thread, you should not have a working directory when you write-share the repository.
So, I tend to say: use core.umask only in shared setups (in which you should not checkout files unless you know exactly what you are doing).
Hmm? (I mean to imitate Linus here, not refer to hidden Markov models.)
Ciao, Dscho
Andreas EricssonRe: git /objects directory created 755 by default?
Johannes Schindelin wrote:
> Hi, > > On Wed, 21 Dec 2005, Junio C Hamano wrote: > > >>Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: >> >> >>>If you don't use git-shell, because the same machine is used for other >>>purposes, it makes sense to introduce >>> >>> [core] >>> umask = 0002 >> >>I agree the setting should not be limited to git-shell, but I do >>not think setting "umask" from git configuration is the right >>way either. For files and directories under $GIT_DIR, maybe >>imposing the policy git configuration file has is OK, but I >>think honoring the user's umask is the right thing for working >>tree files. > > > As we worked out in another thread, you should not have a working > directory when you write-share the repository. >
Which thread was that? I see no particular problem with having a working directory in a write-shared repo. The same care has to be taken there as everywhere (pull before push), but that's nothing new.
-- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231
Johannes SchindelinRe: git /objects directory created 755 by default?
Hi,
On Thu, 22 Dec 2005, Andreas Ericsson wrote:
> Johannes Schindelin wrote: > > Hi, > > > > On Wed, 21 Dec 2005, Junio C Hamano wrote: > > > > > > > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > > > > > > > > > If you don't use git-shell, because the same machine is used for other > > > > purposes, it makes sense to introduce > > > > > > > > [core] > > > > umask = 0002 > > > > > > I agree the setting should not be limited to git-shell, but I do > > > not think setting "umask" from git configuration is the right > > > way either. For files and directories under $GIT_DIR, maybe > > > imposing the policy git configuration file has is OK, but I > > > think honoring the user's umask is the right thing for working > > > tree files. > > > > > > As we worked out in another thread, you should not have a working directory > > when you write-share the repository. > > > > Which thread was that? I see no particular problem with having a working > directory in a write-shared repo. The same care has to be taken there as > everywhere (pull before push), but that's nothing new.
It was the thread "How to set up a shared repository".
Okay, so there you are. You have a write-shared repository with the HEAD checked out. Somebody wants to push to that with different credentials than the user who checked out the files. Do you plainly deny updating the current HEAD?
If you do, then you better give the pushing user (pun intended) a way to update the checked out files. You can do this by (tadaah) setting the umask to 0002 also for working files.
Yes, we could find out exactly where writes happen inside GIT_DIR and plug in shared.umask which is only applied in these cases, but I am totally unconvinced that this is worth the hassle. In my cases, I am perfectly helped by a umask which is respected throughout git, and the patch is simple enough to be reviewed in 5 minutes.
Ciao, Dscho
Andreas EricssonRe: git /objects directory created 755 by default?
Johannes Schindelin wrote:
> Hi, > > On Thu, 22 Dec 2005, Andreas Ericsson wrote: > > >>Johannes Schindelin wrote: >> >>>Hi, >>> >>>On Wed, 21 Dec 2005, Junio C Hamano wrote: >>> >>> >>> >>>>Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: >>>> >>>> >>>> >>>>>If you don't use git-shell, because the same machine is used for other >>>>>purposes, it makes sense to introduce >>>>> >>>>> [core] >>>>> umask = 0002 >>>> >>>>I agree the setting should not be limited to git-shell, but I do >>>>not think setting "umask" from git configuration is the right >>>>way either. For files and directories under $GIT_DIR, maybe >>>>imposing the policy git configuration file has is OK, but I >>>>think honoring the user's umask is the right thing for working >>>>tree files. >>> >>> >>>As we worked out in another thread, you should not have a working directory >>>when you write-share the repository. >>> >> >>Which thread was that? I see no particular problem with having a working >>directory in a write-shared repo. The same care has to be taken there as >>everywhere (pull before push), but that's nothing new. > > > It was the thread "How to set up a shared repository". > > Okay, so there you are. You have a write-shared repository with the HEAD > checked out. Somebody wants to push to that with different credentials > than the user who checked out the files. Do you plainly deny updating the > current HEAD? > > If you do, then you better give the pushing user (pun intended) a way to > update the checked out files. You can do this by (tadaah) setting the > umask to 0002 also for working files. >
Ahh. Sorry. We use this method a lot, really, but always only for running gitk and archaeology tools to check newly pushed changes, so the write-shared repo is only write-shared for remote users, and the local one never does a commit. It's perhaps a bit of a weird setup, but it lets you get an overview faster than gitweb and works well enough with samba. Noted should be that having the repo checked out is merely a convenience thing to let one browse the files at leisure. People know to do git checkout -f HEAD
whenever they want to dig around.
> Yes, we could find out exactly where writes happen inside GIT_DIR and plug > in shared.umask which is only applied in these cases, but I am totally > unconvinced that this is worth the hassle. In my cases, I am perfectly > helped by a umask which is respected throughout git, and the patch is > simple enough to be reviewed in 5 minutes. >
But adding
umask 002
to /etc/bashrc would do exactly the same thing, so why have it a setting for the repository only? In my experience, most servers used for hosting git repos host *lots* of them (look at master.kernel.org), so a server-wide setting really makes much more sense. If the server admin can't be bothered you can always change $HOME/.bashrc.
So long as people remember that .bash_profile isn't read for non-interactive shells this should do nicely. If they can't remember that they won't remember adding the setting to the repository either.
-- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231
Johannes SchindelinRe: git /objects directory created 755 by default?
Hi,
On Thu, 22 Dec 2005, Andreas Ericsson wrote:
> Johannes Schindelin wrote: > > > > Okay, so there you are. You have a write-shared repository with the HEAD > > checked out. Somebody wants to push to that with different credentials than > > the user who checked out the files. Do you plainly deny updating the current > > HEAD? > > > > If you do, then you better give the pushing user (pun intended) a way to > > update the checked out files. You can do this by (tadaah) setting the umask > > to 0002 also for working files. > > > > Ahh. Sorry. We use this method a lot, really, but always only for running gitk > and archaeology tools to check newly pushed changes, so the write-shared repo > is only write-shared for remote users, and the local one never does a commit. > It's perhaps a bit of a weird setup, but it lets you get an overview faster > than gitweb and works well enough with samba. Noted should be that having the > repo checked out is merely a convenience thing to let one browse the files at > leisure. People know to do > git checkout -f HEAD > > whenever they want to dig around.
Better to do this with a post-update hook, right? You can't forget to checkout this way. *Plus* you can make sure the umask is correct in the hook.
> > Yes, we could find out exactly where writes happen inside GIT_DIR and plug > > in shared.umask which is only applied in these cases, but I am totally > > unconvinced that this is worth the hassle. In my cases, I am perfectly > > helped by a umask which is respected throughout git, and the patch is simple > > enough to be reviewed in 5 minutes. > > > > But adding > > umask 002 > > to /etc/bashrc would do exactly the same thing, so why have it a setting for > the repository only? In my experience, most servers used for hosting git repos > host *lots* of them (look at master.kernel.org), so a server-wide setting > really makes much more sense. If the server admin can't be bothered you can > always change $HOME/.bashrc.
In my very special setup, it is a server on which you have your personal files, too. So, setting umask = 0002 globally is not an option.
Furthermore, it just feels wrong to set an option outside of git which is meant *only* for git usage.
> So long as people remember that .bash_profile isn't read for non-interactive > shells this should do nicely. If they can't remember that they won't remember > adding the setting to the repository either.
Problem is, what if one of your users is a tcsh zealot? Or simply forgot to set it. Trouble in China. Also, I simply can not memorize what startup script gets called when.
Ciao, Dscho
Andreas EricssonRe: git /objects directory created 755 by default?
Johannes Schindelin wrote:
> Hi, > > On Thu, 22 Dec 2005, Andreas Ericsson wrote: > > >>Johannes Schindelin wrote: >> >>>Okay, so there you are. You have a write-shared repository with the HEAD >>>checked out. Somebody wants to push to that with different credentials than >>>the user who checked out the files. Do you plainly deny updating the current >>>HEAD? >>> >>>If you do, then you better give the pushing user (pun intended) a way to >>>update the checked out files. You can do this by (tadaah) setting the umask >>>to 0002 also for working files. >>> >> >>Ahh. Sorry. We use this method a lot, really, but always only for running gitk >>and archaeology tools to check newly pushed changes, so the write-shared repo >>is only write-shared for remote users, and the local one never does a commit. >>It's perhaps a bit of a weird setup, but it lets you get an overview faster >>than gitweb and works well enough with samba. Noted should be that having the >>repo checked out is merely a convenience thing to let one browse the files at >>leisure. People know to do >> git checkout -f HEAD >> >>whenever they want to dig around. > > > Better to do this with a post-update hook, right? You can't forget to > checkout this way. *Plus* you can make sure the umask is correct in the > hook. >
What prevents you from setting umask 002 in the hook? If the files are already checked out with some other (write-denying) umask by some other user it will fail regardless of where the umask comes from.
> >>>Yes, we could find out exactly where writes happen inside GIT_DIR and plug >>>in shared.umask which is only applied in these cases, but I am totally >>>unconvinced that this is worth the hassle. In my cases, I am perfectly >>>helped by a umask which is respected throughout git, and the patch is simple >>>enough to be reviewed in 5 minutes. >>> >> >>But adding >> >> umask 002 >> >>to /etc/bashrc would do exactly the same thing, so why have it a setting for >>the repository only? In my experience, most servers used for hosting git repos >>host *lots* of them (look at master.kernel.org), so a server-wide setting >>really makes much more sense. If the server admin can't be bothered you can >>always change $HOME/.bashrc. > > > In my very special setup, it is a server on which you have your personal > files, too. So, setting umask = 0002 globally is not an option. >
scp -p preserves the umask you have on your desktop/laptop, so unless you frequently do
ssh somewhere "echo 'Gawds, this is an awkward way of editing files' >> somefile"
you should be good with the bashrc setting. You can override it from bash_profile to make sure you get a safely sane umask when logging in interactively.
> >>So long as people remember that .bash_profile isn't read for non-interactive >>shells this should do nicely. If they can't remember that they won't remember >>adding the setting to the repository either. > > > Problem is, what if one of your users is a tcsh zealot? Or simply forgot > to set it. Trouble in China. Also, I simply can not memorize what startup > script gets called when. >
tcsh zealot? Not familiar with that one. If you're trying to cover every angle I think you'll be in for a disappointment though. Users are usually fairly ingenious when it comes to finding ways of causing trouble.
As for forgetting to set it, I was talking about the /etc/bashrc file here. There is a /etc/cshrc as well, although this tcsh zealot shell might ignore it.
-- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231
Johannes SchindelinRe: git /objects directory created 755 by default?
Hi,
this is getting silly. The problem is: how to setup a shared repository, i.e. a repository into which different users can push their updates.
Yes, I can work around the fact that git (in its current official version) does not have an option to make that happen.
It is just awfully cumbersome. And that is what good software should prevent. Especially if it is *that* easy.
Hth, Dscho
Andreas EricssonRe: git /objects directory created 755 by default?
Johannes Schindelin wrote:
> Hi, > > this is getting silly. The problem is: how to setup a shared repository, > i.e. a repository into which different users can push their updates. >
You're simplifying. Your question was "How can I set up a repository for multiple users to write to without setting a global umask for non-interactive shells?"
Junio said: "I agree the setting should not be limited to git-shell, but I do not think setting "umask" from git configuration is the right way either. For files and directories under $GIT_DIR, maybe imposing the policy git configuration file has is OK, but I think honoring the user's umask is the right thing for working tree files."
which I whole-heartedly agree with. I'd be completely furious if a tool ignored the umask I use for checking out files of a local repository just because I happen to do some work at the machine where the repo is stored (I imagine this couldn't possibly affect repositories cloned remotely, although that would surely have me going ballistic).
You answered that it would be good for hooks as well, although those can set their own umask easily enough (if you forget it there, you'll be hastily reminded the first time it breaks, so no real harm done).
The problem as I see it is to update only the $GIT_DIR files with the proper umask (or rather, just the objects/ and refs/ directories, since $GIT_DIR/. is never touched after being created and the other are for repo maintainers only).
Enter the nifty git-receive-pack, which does all the writing when a repo is being pushed to, unless bypassed from the /git/foo working tree for the /git/foo/.git repository. The latter is already discouraged, so we might as well ignore that. It's also nice because it will never mess with files that are for the repo maintainer only, although hooks can ofcourse do whatever they like to those files provided the repo maintainer allows it.
Now it's time to go home, but I'll have a patch by tonight unless you beat me to it. :)
-- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231
Johannes SchindelinRe: git /objects directory created 755 by default?
Hi,
On Thu, 22 Dec 2005, Andreas Ericsson wrote:
> Johannes Schindelin wrote: > > Hi, > > > > this is getting silly. The problem is: how to setup a shared repository, > > i.e. a repository into which different users can push their updates. > > > > You're simplifying. Your question was > "How can I set up a repository for multiple users to write to without setting > a global umask for non-interactive shells?"
No, I am not. My question really was: how do I setup a shared repository?
Now, my intention was to make it as easy as possible.
> Junio said: > "I agree the setting should not be limited to git-shell, but I do > not think setting "umask" from git configuration is the right > way either. For files and directories under $GIT_DIR, maybe > imposing the policy git configuration file has is OK, but I > think honoring the user's umask is the right thing for working > tree files."
IMHO Junio is wrong here. If the repository is write-shared, then the working directory should be write-shared as well (or checkout should be DENIED), else you get all kinds of problems.
> which I whole-heartedly agree with. I'd be completely furious if a tool > ignored the umask I use for checking out files of a local repository just > because I happen to do some work at the machine where the repo is stored (I > imagine this couldn't possibly affect repositories cloned remotely, although > that would surely have me going ballistic).
I do not understand what you mean by "repositories cloned remotely".
And if you really are working in the working directory of the shared repository, and a user (I know I would do it just to annoy you) pushes a new HEAD while you have modified files, you deserve what you get: a complete mess.
As for setting the umask only when writing into $GIT_DIR: unless somebody convinces me that it solves a problem, this is unncessary work.
You are free to ignore my warnings and my patch, I got no problem with that.
You are also free to wait for users to complain why this and that breaks, or why setting up a shared repository has to be hard, and apply my patch then.
Hth, Dscho
Junio C HamanoRe: git /objects directory created 755 by default?
Andreas Ericsson <ae@op5.se> writes:
> Junio said: > "I agree the setting should not be limited to git-shell, but I do > not think setting "umask" from git configuration is the right > way either. For files and directories under $GIT_DIR, maybe > imposing the policy git configuration file has is OK, but I > think honoring the user's umask is the right thing for working > tree files."
I think this needs qualifying.
When we talk about "CVS-style shared repository", we know what it is -- there is no such thing as "*the* working tree associated with the repository" and there is no room for disagreement.
The workflow your shared repository implies is that there is an associated working tree with that repository, and the working tree should allow updates by participants who are allowed to create new things in .git/objects and update .git/refs/. If you assume that is the only valid use case for non-naked shared repository, then what I said above is not needed. It does not make any sense to have anything stricter than 007 as umask in such a case. But is it the only valid use case?
I could give each of the gitsters I trust an git-shell account on my private machine and prepare refs/heads/rcpt/js branch for you and refs/heads/rcpt/ae for Andreas to push into (I would use Carl's per branch push policy to make sure those "receipt branches" are the only ones you guys can push into if I did so).
Then instead of sending "I now have this public repository and have goodies for git improvement; please pull" e-mail to me, you could push into your branch. I will keep working on master (and my own topic branches), with whatever branch checked out in the working tree, and merge from those rcpt branches at my leisure. You guys are not allowed to touch my working tree, though.
In such a scenario, there is no reason to forbid me from applying umask 022 to my working tree files, even though making sure that fan-out directories of .git/objects/ *I* lazily create can be writable by you is essential.
I have a feeling that it might be good enough to modify safe_create_leading_directories() to chmod(0777) after creating a new directory under .git/ (or limit it to .git/objects/). The repository administrator can restrict things further by chmod 0770 .git/ as needed.
Johannes SchindelinRe: git /objects directory created 755 by default?
Hi,
On Thu, 22 Dec 2005, Junio C Hamano wrote:
> When we talk about "CVS-style shared repository", we know what > it is -- there is no such thing as "*the* working tree > associated with the repository" and there is no room for > disagreement.
This is what I mean by shared repository.
> I could give each of the gitsters I trust an git-shell account > on my private machine and prepare refs/heads/rcpt/js branch for > you and refs/heads/rcpt/ae for Andreas to push into (I would use > Carl's per branch push policy to make sure those "receipt > branches" are the only ones you guys can push into if I did so). > > Then instead of sending "I now have this public repository and > have goodies for git improvement; please pull" e-mail to me, you > could push into your branch. I will keep working on master (and > my own topic branches), with whatever branch checked out in the > working tree, and merge from those rcpt branches at my leisure. > You guys are not allowed to touch my working tree, though.
This has some merit, for example, when some of the contributors have no public repository.
> In such a scenario, there is no reason to forbid me from > applying umask 022 to my working tree files, even though making > sure that fan-out directories of .git/objects/ *I* lazily create > can be writable by you is essential. > > I have a feeling that it might be good enough to modify > safe_create_leading_directories() to chmod(0777) after creating > a new directory under .git/ (or limit it to .git/objects/). The > repository administrator can restrict things further by chmod > 0770 .git/ as needed.
And then somebody comes along and allows world access by chmod(0775) and does not realize that *everybody* can delete packs, objects and what-nots in GIT_DIR.
Given the complexity we are talking about, and the needs which are not at all that complicated, why not just go with core.umask until somebody *needs* core.repositoryumask?
Ciao, Dscho
Junio C HamanoRe: git /objects directory created 755 by default?
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> And then somebody comes along and allows world access by chmod(0775) and > does not realize that *everybody* can delete packs, objects and what-nots > in GIT_DIR.
That somebody has to be somebody who owns .git directory not just a group member, so that is not a serious objection either, but you need to realize I was joking with 0777 -- a saner default would obviously be 0775. Otherwise you would not be able to server it from gitweb safely -- http server is typically not a group member.
> Given the complexity we are talking about, and the needs which are not at > all that complicated, why not just go with core.umask until somebody > *needs* core.repositoryumask?
I am afraid that is going backwards. Nobody *needs* core.umask either, but we are still talking about this. That is because you wanted to make things easier for people, and I agree with you that it would be nicer if we did not require people set umask to sane values suitable for group work themselves, but somehow we did that automatically for them. The longer I think about it, however, the more I feel this is a lost cause.
Earlier, I suggested git-shell one-liner, only because I thought git-shell users (or administrators that support git-shell users) may not have any way to set the umask to sane values themselves, but I think that should also be doable by telling sshd what the initial umask of the users should be. And that was where this umask discussion was started, but I think not touching umask at all is the right direction.
Your core.umask would make sure the .git/objects/ directory would be suitable for other members, but git is not the only tool the people would use in the working tree. To work well with an editor that does not overwrite an existing file but does creat/rename upon saving would require you to have a sane umask if the user adopts your "shared working tree writable by all members" workflow. Running "make" in the working tree would leave object files, worse yet in a temporary build directory make created, with permission bits masked with your umask, making it imposible to run "make clean" for other members.
Regardless of where and how people come from to work in the working tree, they need to set umask appropriately anyway.
The only possible issue is one umask might not be sufficient, but unfortunately you can have only one umask at a time. The example of "receiption branches" is not a shared repository for me in the strict sense, but allows for you to push into. I cannot work with umask 022 in such a repository even if I wanted to have files in the working tree honor tighter umask. To deal also with such cases, not mucking with umask but solving the problem in a more direct way may make more sense -- namely we should be able to say "such and such things under .git/ in this repository must be ug+rw regardless of user's umask".
Johannes SchindelinRe: git /objects directory created 755 by default?
Hi,
On Thu, 22 Dec 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > > And then somebody comes along and allows world access by chmod(0775) and > > does not realize that *everybody* can delete packs, objects and what-nots > > in GIT_DIR. > > That somebody has to be somebody who owns .git directory not > just a group member, so that is not a serious objection either, > but you need to realize I was joking with 0777 -- a saner > default would obviously be 0775. Otherwise you would not be > able to server it from gitweb safely -- http server is typically > not a group member.
I was talking about somebody who has only one server for everything: mail, web and git. So this somebody would be the owner of .git.
> > Given the complexity we are talking about, and the needs which are not at > > all that complicated, why not just go with core.umask until somebody > > *needs* core.repositoryumask? > > I am afraid that is going backwards. Nobody *needs* core.umask > either, but we are still talking about this.
Well, I do.
> Your core.umask would make sure the .git/objects/ directory > would be suitable for other members, but git is not the only > tool the people would use in the working tree. To work well > with an editor that does not overwrite an existing file but does > creat/rename upon saving would require you to have a sane umask > if the user adopts your "shared working tree writable by all > members" workflow. Running "make" in the working tree would > leave object files, worse yet in a temporary build directory > make created, with permission bits masked with your umask, > making it imposible to run "make clean" for other members.
Hmm. That is convincing.
> we should be able to say "such and such things under .git/ in this > repository must be ug+rw regardless of user's umask".
Yes, I tried to avoid that.
Ciao, Dscho
Junio C HamanoRe: git /objects directory created 755 by default?
Andreas Ericsson <ae@op5.se> writes:
> Ahh. Sorry. We use this method a lot, really, but always only for > running gitk and archaeology tools to check newly pushed changes, so the > write-shared repo is only write-shared for remote users, and the local > one never does a commit.
Do you need a working tree to run gitk?
Andreas EricssonRe: git /objects directory created 755 by default?
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes: > > >>Ahh. Sorry. We use this method a lot, really, but always only for >>running gitk and archaeology tools to check newly pushed changes, so the >>write-shared repo is only write-shared for remote users, and the local >>one never does a commit. > > > Do you need a working tree to run gitk? >
No, but it makes for a nice shorthand, especially since most of our projects are riddled with sub-repos.
-- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231
Alex RiesenRe: git /objects directory created 755 by default?
On 12/21/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > > > > [core] > > > umask = 0002 > So, I tend to say: use core.umask only in shared setups (in which you > should not checkout files unless you know exactly what you are doing).
May be "shell.umask" or "shared.umask" ?
Johannes SchindelinRe: git /objects directory created 755 by default?
Hi,
On Thu, 22 Dec 2005, Alex Riesen wrote:
> On 12/21/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > > > > > > > > [core] > > > > umask = 0002 > > So, I tend to say: use core.umask only in shared setups (in which you > > should not checkout files unless you know exactly what you are doing). > > May be "shell.umask" or "shared.umask" ?
What would shell.umask do? Be set only when git-shell is called? Then you better have the policy to access that particular repository *only* via git-shell. Voila, it is the same effect as of core.umask.
What would shared.umask do? Be set only when writing to GIT_DIR? This is a major task, since you have to find out which writes are to the working directory, which ones go to GIT_DIR.
And you have to workout a policy (as I just answered in this thread) how to deal with a checked out HEAD where you can't write to the working directory (or at least modify the checked out files).
The sanest way I can think of is either to disallow checkout, or to make the files writable to the group. Both methods do fine with core.umask.
Now that I think of it: A third possibility is to disallow pushing to the checked out HEAD. Is this desirable? I think not. The user who works in the working directory exclusively would have to keep track of the pushed ref herself, instead of the user who pushed the ref. Sounds silly to me.
Hth, Dscho
Alex RiesenRe: git /objects directory created 755 by default?
On 12/22/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > > > > > > > > [core] > > > > > umask = 0002 > > > So, I tend to say: use core.umask only in shared setups (in which you > > > should not checkout files unless you know exactly what you are doing). > > > > May be "shell.umask" or "shared.umask" ? > > What would shell.umask do? Be set only when git-shell is called? Then you > better have the policy to access that particular repository *only* via > git-shell. Voila, it is the same effect as of core.umask.
I mean it to be set only when git-shell called, but with explicit semantics ("for git-shell only").
> What would shared.umask do? Be set only when writing to GIT_DIR? This is a > major task, since you have to find out which writes are to the working > directory, which ones go to GIT_DIR.
shared.mask = shell.mask. Just a name to express what it is for
Johannes SchindelinRe: git /objects directory created 755 by default?
Hi,
On Thu, 22 Dec 2005, Alex Riesen wrote:
> On 12/22/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > What would shell.umask do? Be set only when git-shell is called? Then you
> > better have the policy to access that particular repository *only* via
> > git-shell. Voila, it is the same effect as of core.umask.
>
> I mean it to be set only when git-shell called, but with explicit semantics
> ("for git-shell only").But if somebody writes to the same repository with another umask, say 0022, you have problems. Example:
- I push -- via ssh/bash -- to the repository. The ref refs/heads/bruchpilot is updated (mode: 0644).
- My colleague pushes -- via ssh/git-shell -- to the repository. When she tries to write refs/heads/bruchpilot, it fails, even if she set the correct umask.
See what I mean? It makes no sense to allow different umasks on the repository.
> > What would shared.umask do? Be set only when writing to GIT_DIR? This is a > > major task, since you have to find out which writes are to the working > > directory, which ones go to GIT_DIR. > > shared.mask = shell.mask. Just a name to express what it is for
You do mean different umasks for different access methods, don't you? See above why I don't think that makes sense.
Ciao, Dscho
Alex RiesenRe: git /objects directory created 755 by default?
On 12/22/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > >
> > > What would shell.umask do? Be set only when git-shell is called? Then you
> > > better have the policy to access that particular repository *only* via
> > > git-shell. Voila, it is the same effect as of core.umask.
> >
> > I mean it to be set only when git-shell called, but with explicit semantics
> > ("for git-shell only").
>
> But if somebody writes to the same repository with another umask, say
> 0022, you have problems. Example:
>
> - I push -- via ssh/bash -- to the repository. The ref refs/heads/bruchpilot
> is updated (mode: 0644).
>
> - My colleague pushes -- via ssh/git-shell -- to the repository. When she
> tries to write refs/heads/bruchpilot, it fails, even if she set the
> correct umask.
>
> See what I mean? It makes no sense to allow different umasks on the
> repository.Does it make sense to allow different access methods to a shared repository?
> > > What would shared.umask do? Be set only when writing to GIT_DIR? This is a > > > major task, since you have to find out which writes are to the working > > > directory, which ones go to GIT_DIR. > > > > shared.mask = shell.mask. Just a name to express what it is for > > You do mean different umasks for different access methods, don't you? See > above why I don't think that makes sense.
No, just different names for the same access method.
Johannes SchindelinRe: git /objects directory created 755 by default?
Hi,
On Thu, 22 Dec 2005, Alex Riesen wrote:
> Does it make sense to allow different access methods to a shared repository?
My point is: regardless if you allow different access methods or not, you only need one method to set a repository-wide umask.
Ciao, Dscho