git /objects directory created 755 by default?

git /objects directory created 755 by default?

[Martin Langhoff]

Junio,

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

Re: git /objects directory created 755 by default?

[Junio C Hamano]

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.

Re: git /objects directory created 755 by default?

[Junio C Hamano]

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

to 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 },
 };
 

Re: git /objects directory created 755 by default?

[Martin Langhoff]

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

Re: git /objects directory created 755 by default?

[Junio C Hamano]

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:
 

Re: git /objects directory created 755 by default?

[Junio C Hamano]

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

Re: git /objects directory created 755 by default?

[Martin Langhoff]

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

Re: git /objects directory created 755 by default?

[Martin Langhoff]

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

Re: git /objects directory created 755 by default?

[Junio C Hamano]

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

Re: git /objects directory created 755 by default?

[Martin Langhoff]

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

Re: git /objects directory created 755 by default?

[Johannes Schindelin]

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

Re: git /objects directory created 755 by default?

[Junio C Hamano]

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.

Re: git /objects directory created 755 by default?

[Johannes Schindelin]

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

Re: git /objects directory created 755 by default?

[Ben Clifford]

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

-- 

Re: git /objects directory created 755 by default?

[Andreas Ericsson]

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

Re: git /objects directory created 755 by default?

[Alex Riesen]

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

Re: git /objects directory created 755 by default?

[Johannes Schindelin]

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

Re: git /objects directory created 755 by default?

[Johannes Schindelin]

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

Re: git /objects directory created 755 by default?

[Andreas Ericsson]

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

Re: git /objects directory created 755 by default?

[Johannes Schindelin]

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

Re: git /objects directory created 755 by default?

[Alex Riesen]

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

Re: git /objects directory created 755 by default?

[Johannes Schindelin]

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

Re: git /objects directory created 755 by default?

[Alex Riesen]

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.

Re: git /objects directory created 755 by default?

[Johannes Schindelin]

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

Re: git /objects directory created 755 by default?

[Andreas Ericsson]

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

Re: git /objects directory created 755 by default?

[Johannes Schindelin]

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

Re: git /objects directory created 755 by default?

[Andreas Ericsson]

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

Re: git /objects directory created 755 by default?

[Johannes Schindelin]

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

Re: git /objects directory created 755 by default?

[Junio C Hamano]

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.

Re: git /objects directory created 755 by default?

[Johannes Schindelin]

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

Re: git /objects directory created 755 by default?

[Junio C Hamano]

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

Re: git /objects directory created 755 by default?

[Johannes Schindelin]

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

Re: git /objects directory created 755 by default?

[Junio C Hamano]

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?

Re: git /objects directory created 755 by default?

[Andreas Ericsson]

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