{"thread":{"id":"2887","subject":"git /objects directory created 755 by default?","startedAt":"2005-12-20T23:25:07Z","lastAt":"2005-12-23T12:07:53Z","messageCount":34,"participants":["Martin Langhoff","Junio C Hamano","Johannes Schindelin","Andreas Ericsson","Alex Riesen","Ben Clifford"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"13845","messageId":"46a038f90512201525k5eb7cf62u65de2cd51424df37@mail.gmail.com","threadId":"2887","inReplyTo":null,"subject":"git /objects directory created 755 by default?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-12-20T23:25:07Z","receivedAt":"2005-12-20T23:25:07Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"Junio,\n\nSince git changed to creating the objects subdirectories \"on demand\",\nthese are created 755 regardless of the user's umask. This is quite\ninconvenient in (\"cvs style\") team-shared repositories, which work\ngreat otherwise.\n\nDidn't find any relevant discussion in the archives... I am not sure\nif this is by design. In any case it is something we could work around\nwith a post-update hook on the server side (and I'd be happy to\ndocument).\n\ncheers,\n\n\nmartin\n"},{"id":"13846","messageId":"7vacevgwqr.fsf@assigned-by-dhcp.cox.net","threadId":"2887","inReplyTo":"46a038f90512201525k5eb7cf62u65de2cd51424df37@mail.gmail.com","subject":"Re: git /objects directory created 755 by default?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-20T23:43:56Z","receivedAt":"2005-12-20T23:43:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Langhoff <martin.langhoff@gmail.com> writes:\n\n> Since git changed to creating the objects subdirectories \"on demand\",\n> these are created 755 regardless of the user's umask. This is quite\n> inconvenient in (\"cvs style\") team-shared repositories, which work\n> great otherwise.\n\nHmph.\n\nI have 002 as umask. .git/objects or .git/objects/[0-9a-f]{2}\ndirectories are created 0775 for me.\n\nDo we have hardcoded 0755 that we need to change to 0777\nsomewhere?  sha1_file.c::safe_create_leading_directories() is\nthe primary code that creates directories lazily, and we mkdir\nwith 0777 there.\n"},{"id":"13847","messageId":"7vlkyffcxp.fsf@assigned-by-dhcp.cox.net","threadId":"2887","inReplyTo":"7vacevgwqr.fsf@assigned-by-dhcp.cox.net","subject":"Re: git /objects directory created 755 by default?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-21T01:37:06Z","receivedAt":"2005-12-21T01:37:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> Martin Langhoff <martin.langhoff@gmail.com> writes:\n>\n>> Since git changed to creating the objects subdirectories \"on demand\",\n>> these are created 755 regardless of the user's umask. This is quite\n>> inconvenient in (\"cvs style\") team-shared repositories, which work\n>> great otherwise.\n>\n> Hmph.\n>\n> I have 002 as umask. .git/objects or .git/objects/[0-9a-f]{2}\n> directories are created 0775 for me.\n\nMartin, is this happening when your developers push into the\nshared repo?  If so, do your developers use git-shell?  Do their\numask set properly even when they come over ssh and gets into\nnoninteractive shell?  What do they see when they do this?\n\n\t$ ssh shared.repo.machine.example.com umask\n\nthe answer may wall be \"What do you think I am, A shell?\", or\n0022.\n\nThe git-shell command is designed to be not git aware (it does\nnot know how a git repository looks like, nor does not know all\nthe commands it can handle right now happen to take the\nrepository directory as their first parameter).  If we do not\nmind butchering things, we could introduce:\n\n\t[shell]\n        \tumask = 0002\n\nto the configuration file, and do something like this (not even\ncompile tested, and I am not sure what else it breaks):\n\n---\ndiff --git a/shell.c b/shell.c\nindex cd31618..33898f8 100644\n--- a/shell.c\n+++ b/shell.c\n@@ -1,15 +1,34 @@\n #include \"cache.h\"\n #include \"quote.h\"\n \n-static int do_generic_cmd(const char *me, char *arg)\n+static int shell_umask = 0002; /* default */\n+\n+static int slurp_repository_umask(const char *var, const char *value)\n+{\n+\tif (!strcmp(var, \"shell.umask\"))\n+\t\tshell_umask = git_config_int(value);\n+\telse\n+\t\treturn git_default_config(var, value);\n+\treturn 0;\n+}\n+\n+/*\n+ * These commands take arg == git repository directory.\n+ */\n+static int do_git_repo_cmd(const char *me, char *arg)\n {\n \tconst char *my_argv[4];\n \n \tif (!arg || !(arg = sq_dequote(arg)))\n \t\tdie(\"bad argument\");\n \n+\tif (!enter_repo(arg, 0))\n+\t\tdie(\"'%s': Nah -- not a git repository\", arg);\n+\tgit_config(slurp_repository_umask);\n+\tumask(shell_umask);\n+\n \tmy_argv[0] = me;\n-\tmy_argv[1] = arg;\n+\tmy_argv[1] = \".\";\n \tmy_argv[2] = NULL;\n \n \treturn execvp(me, (char**) my_argv);\n@@ -19,8 +38,8 @@ static struct commands {\n \tconst char *name;\n \tint (*exec)(const char *me, char *arg);\n } cmd_list[] = {\n-\t{ \"git-receive-pack\", do_generic_cmd },\n-\t{ \"git-upload-pack\", do_generic_cmd },\n+\t{ \"git-receive-pack\", do_git_repo_cmd },\n+\t{ \"git-upload-pack\", do_git_repo_cmd },\n \t{ NULL },\n };\n \n"},{"id":"13850","messageId":"46a038f90512201828w618a64dexc22a64b8b6bc2b70@mail.gmail.com","threadId":"2887","inReplyTo":"7vlkyffcxp.fsf@assigned-by-dhcp.cox.net","subject":"Re: git /objects directory created 755 by default?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-12-21T02:28:46Z","receivedAt":"2005-12-21T02:28:46Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 12/21/05, Junio C Hamano <junkio@cox.net> wrote:\n> Martin, is this happening when your developers push into the\n> shared repo?\n\nyes...\n\n> If so, do your developers use git-shell?\n\nno...\n\n>  Do their\n> umask set properly even when they come over ssh and gets into\n> noninteractive shell?\n\nOh DUH. PEBKAK. .bash_profile != .bashrc\n\nI think I owe you an apology and a couple of beers -- I'm an idiot. No\nwonder I feel \"at home\" with \"git\"...\n\ncheers,\n\n\nmartin\n"},{"id":"13852","messageId":"7vr787dp9r.fsf@assigned-by-dhcp.cox.net","threadId":"2887","inReplyTo":"46a038f90512201828w618a64dexc22a64b8b6bc2b70@mail.gmail.com","subject":"Re: git /objects directory created 755 by default?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-21T04:53:36Z","receivedAt":"2005-12-21T04:53:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Langhoff <martin.langhoff@gmail.com> writes:\n\n> I think I owe you an apology and a couple of beers...\n\nNah, you do not owe me anything.  Does something like this look\ngood?\n\n-- >8 --\n[PATCH] A shared repository should be writable by members.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n\n---\ndiff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt\nindex 1683f0b..1b85cab 100644\n--- a/Documentation/tutorial.txt\n+++ b/Documentation/tutorial.txt\n@@ -1625,7 +1625,9 @@ cooperation you are probably more famili\n For this, set up a public repository on a machine that is\n reachable via SSH by people with \"commit privileges\".  Put the\n committers in the same user group and make the repository\n-writable by that group.\n+writable by that group.  Make sure their umasks are set up to\n+allow group members to write into directories other members\n+have created.\n \n You, as an individual committer, then:\n \n"},{"id":"13853","messageId":"7vacevdoti.fsf@assigned-by-dhcp.cox.net","threadId":"2887","inReplyTo":"46a038f90512201828w618a64dexc22a64b8b6bc2b70@mail.gmail.com","subject":"Re: git /objects directory created 755 by default?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-21T05:03:21Z","receivedAt":"2005-12-21T05:03:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Langhoff <martin.langhoff@gmail.com> writes:\n\n>> If so, do your developers use git-shell?\n>\n> no...\n\nWhile we established that your problem did not have anything to\ndo with git-shell, I am tempted to do something like this.\n\nThoughts?\n\n-- >8 --\n[PATCH] Force group writable umask in git-shell\n\nUsually I do not like hardcoded policy in programs, but use of\ngit-shell is already a policy decision by the repository\nadministrator to use the shared repository style of development,\nand I cannot think of a reason to forbid group (and self, but\nthat is obvious) writability in such use scenario.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n\n---\n\ndiff --git a/shell.c b/shell.c\nindex cd31618..40a2a97 100644\n--- a/shell.c\n+++ b/shell.c\n@@ -52,6 +52,10 @@ int main(int argc, char **argv)\n \t\tdefault:\n \t\t\tcontinue;\n \t\t}\n+\t\t/* Make sure myself and my group members can write\n+\t\t * into what I create.\n+\t\t */\n+\t\tumask(umask(0) & ~0770);\n \t\texit(cmd->exec(cmd->name, arg));\n \t}\n \tdie(\"unrecognized command '%s'\", prog);\n"},{"id":"13854","messageId":"46a038f90512202110i5f4a4d6fu16981f5801798717@mail.gmail.com","threadId":"2887","inReplyTo":"7vr787dp9r.fsf@assigned-by-dhcp.cox.net","subject":"Re: git /objects directory created 755 by default?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-12-21T05:10:16Z","receivedAt":"2005-12-21T05:10:16Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 12/21/05, Junio C Hamano <junkio@cox.net> wrote:\n> Martin Langhoff <martin.langhoff@gmail.com> writes:\n>\n> > I think I owe you an apology and a couple of beers...\n>\n> Nah, you do not owe me anything.  Does something like this look\n> good?\n\nYup, makes sense to me. I often explain it as \"same file permissions\nand access model as you'd use with CVS\".\n\ncheers,\n\n\nmartin\n"},{"id":"13855","messageId":"46a038f90512202115o652d8e00v86182302513d1319@mail.gmail.com","threadId":"2887","inReplyTo":"7vacevdoti.fsf@assigned-by-dhcp.cox.net","subject":"Re: git /objects directory created 755 by default?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-12-21T05:15:43Z","receivedAt":"2005-12-21T05:15:43Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 12/21/05, Junio C Hamano <junkio@cox.net> wrote:\n> [PATCH] Force group writable umask in git-shell\n>\n> Usually I do not like hardcoded policy in programs, but use of\n> git-shell is already a policy decision by the repository\n> administrator to use the shared repository style of development,\n> and I cannot think of a reason to forbid group (and self, but\n> that is obvious) writability in such use scenario.\n\nCould git-shell also be used by a SourceForge-like project, offering\nper-developer git repositories? If they are using the (BSDish?)\nconvention of not having a group per user this could backfire.\n\nDoes any unix these days _not_ use a group per user?\n\ncheers,\n\n\nmartin\n"},{"id":"13856","messageId":"7vzmmvc9l1.fsf@assigned-by-dhcp.cox.net","threadId":"2887","inReplyTo":"46a038f90512202115o652d8e00v86182302513d1319@mail.gmail.com","subject":"Re: git /objects directory created 755 by default?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-21T05:17:46Z","receivedAt":"2005-12-21T05:17:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Langhoff <martin.langhoff@gmail.com> writes:\n\n> Could git-shell also be used by a SourceForge-like project, offering\n> per-developer git repositories? If they are using the (BSDish?)\n> convention of not having a group per user this could backfire.\n\nFair enough.  And I realize that the initial umask should be\nconfigurable by the administrator who prepares ssh accounts\nsomehow (I do not know exactly how though).\n"},{"id":"13857","messageId":"46a038f90512202123p5c7fbbe7qbf930abd8965a88c@mail.gmail.com","threadId":"2887","inReplyTo":"7vzmmvc9l1.fsf@assigned-by-dhcp.cox.net","subject":"Re: git /objects directory created 755 by default?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-12-21T05:23:57Z","receivedAt":"2005-12-21T05:23:57Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 12/21/05, Junio C Hamano <junkio@cox.net> wrote:\n> Martin Langhoff <martin.langhoff@gmail.com> writes:\n>\n> > Could git-shell also be used by a SourceForge-like project, offering\n> > per-developer git repositories? If they are using the (BSDish?)\n> > convention of not having a group per user this could backfire.\n>\n> Fair enough.  And I realize that the initial umask should be\n> configurable by the administrator who prepares ssh accounts\n> somehow (I do not know exactly how though).\n\nSomething like rssh, which supports rsync, cvs and sftp (and should\nsupport git!), can set the umask based on a config. I think\n/etc/bashrc would work too. In Eduforge, I think we have /etc/skel\nwith a group-friendly umask.\n\ncheers,\n\n\nmartin\n"},{"id":"13865","messageId":"Pine.LNX.4.63.0512211502130.25834@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2887","inReplyTo":"7vlkyffcxp.fsf@assigned-by-dhcp.cox.net","subject":"Re: git /objects directory created 755 by default?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-12-21T15:35:18Z","receivedAt":"2005-12-21T15:35:18Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 20 Dec 2005, Junio C Hamano wrote:\n\n> \t[shell]\n>         \tumask = 0002\n\nIf you don't use git-shell, because the same machine is used for other \npurposes, it makes sense to introduce\n\n\t[core]\n\t\tumask = 0002\n\nHow about this:\n\n---\n[PATCH] Introduce core.umask\n\nThis makes it possible to setup a shared git repository by setting\n\n\t[core]\n\t\tumask = 0002\n\nint the template config file.\n\nThis patch makes sure even git-init-db uses it.\n\nSigned-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>\n\n---\n\n init-db.c |   21 ++++++++++++++-------\n setup.c   |    4 ++++\n 2 files changed, 18 insertions(+), 7 deletions(-)\n\nfaa7d4b101211ac1993d73bb3d02e8a6d2c40734\ndiff --git a/init-db.c b/init-db.c\nindex 41576bd..26812ce 100644\n--- a/init-db.c\n+++ b/init-db.c\n@@ -164,6 +164,7 @@ static void create_default_files(const c\n \tunsigned char sha1[20];\n \tstruct stat st1;\n \tchar repo_version_string[10];\n+\tmode_t mask, mask2;\n \n \tif (len > sizeof(path)-50)\n \t\tdie(\"insane git directory %s\", git_dir);\n@@ -172,6 +173,19 @@ static void create_default_files(const c\n \tif (len && path[len-1] != '/')\n \t\tpath[len++] = '/';\n \n+\t/* First copy the templates -- we might have the default\n+\t * config file there, in which case we would want to read\n+\t * from it after installing.\n+\t * The config file may contain a umask...\n+\t */\n+\tpath[len] = 0;\n+\tumask(mask = umask(0));\n+\tcopy_templates(path, len, template_path);\n+\tif (mask != (mask2 = umask(mask))) {\n+\t\tumask(mask2);\n+\t\tchmod(path, 0777 & ~mask2);\n+\t}\n+\n \t/*\n \t * Create .git/refs/{heads,tags}\n \t */\n@@ -182,13 +196,6 @@ static void create_default_files(const c\n \tstrcpy(path + len, \"refs/tags\");\n \tsafe_create_dir(path);\n \n-\t/* First copy the templates -- we might have the default\n-\t * config file there, in which case we would want to read\n-\t * from it after installing.\n-\t */\n-\tpath[len] = 0;\n-\tcopy_templates(path, len, template_path);\n-\n \tgit_config(git_default_config);\n \n \t/*\ndiff --git a/setup.c b/setup.c\nindex d3556ed..4e4cb46 100644\n--- a/setup.c\n+++ b/setup.c\n@@ -180,6 +180,10 @@ int check_repository_format_version(cons\n {\n        if (strcmp(var, \"core.repositoryformatversion\") == 0)\n                repository_format_version = git_config_int(var, value);\n+\n+       else if (!strcmp(var, \"core.umask\"))\n+\t       umask(git_config_int(var, value));\n+\n        return 0;\n }\n \n-- \n1.0.0\n"},{"id":"13893","messageId":"7vek465cev.fsf@assigned-by-dhcp.cox.net","threadId":"2887","inReplyTo":"Pine.LNX.4.63.0512211502130.25834@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git /objects directory created 755 by default?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-21T22:10:48Z","receivedAt":"2005-12-21T22:10:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> If you don't use git-shell, because the same machine is used for other \n> purposes, it makes sense to introduce\n>\n> \t[core]\n> \t\tumask = 0002\n\nI agree the setting should not be limited to git-shell, but I do\nnot think setting \"umask\" from git configuration is the right\nway either.  For files and directories under $GIT_DIR, maybe\nimposing the policy git configuration file has is OK, but I\nthink honoring the user's umask is the right thing for working\ntree files.\n"},{"id":"13895","messageId":"Pine.LNX.4.63.0512212317400.18684@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2887","inReplyTo":"7vek465cev.fsf@assigned-by-dhcp.cox.net","subject":"Re: git /objects directory created 755 by default?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-12-21T22:20:26Z","receivedAt":"2005-12-21T22:20:26Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 21 Dec 2005, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > If you don't use git-shell, because the same machine is used for other \n> > purposes, it makes sense to introduce\n> >\n> > \t[core]\n> > \t\tumask = 0002\n> \n> I agree the setting should not be limited to git-shell, but I do\n> not think setting \"umask\" from git configuration is the right\n> way either.  For files and directories under $GIT_DIR, maybe\n> imposing the policy git configuration file has is OK, but I\n> think honoring the user's umask is the right thing for working\n> tree files.\n\nAs we worked out in another thread, you should not have a working \ndirectory when you write-share the repository.\n\nSo, I tend to say: use core.umask only in shared setups (in which you \nshould not checkout files unless you know exactly what you are doing).\n\nHmm? (I mean to imitate Linus here, not refer to hidden Markov models.)\n\nCiao,\nDscho\n"},{"id":"13969","messageId":"Pine.OSX.4.64.0512221248260.6087@piva.local","threadId":"2887","inReplyTo":"46a038f90512202115o652d8e00v86182302513d1319@mail.gmail.com","subject":"Re: git /objects directory created 755 by default?","fromName":"Ben Clifford","fromEmail":"benc@hawaga.org.uk","sentAt":"2005-12-22T03:46:16Z","receivedAt":"2005-12-22T03:46:16Z","isPatch":false,"sender":{"key":"benc@hawaga.org.uk","avatar":"https://gravatar.com/avatar/c7ce083471287f8e77b69dd147f757799d1efdd740727fd7e3003f33e88be898?d=mp&s=160"},"body":"\n> Could git-shell also be used by a SourceForge-like project, offering\n> per-developer git repositories? If they are using the (BSDish?)\n> convention of not having a group per user this could backfire.\n>\n> Does any unix these days _not_ use a group per user?\n\nAt least two reasonably sized shops that I have worked with previously do \nnot have group-per-user (and I think two others but I cannot remember \nabout those) - they have centrally administered user accounts and just \nhave groups like 'i am in department X', or 'I am allowed to write into \n$SOMEPROJECT cvs'.\n\nBut that's not a per-unix decision, its a per-organisation administrative \ndecision.\n\nIn any case, their usage of groups wrt shared CVS would not have a problem \nwith a 77x mask, though there might be problems (I haven't thought about \nit enough) with the setgid(?) bit on directories - we used to hit this \noccasionally in CVS when a directory would end up being created with a \nuser's primary group rather than the 'I am allowed to write into CVS' \ngroup. There is too much wine in me at the moment to work out if its also \na problem for git...\n\n-- \n"},{"id":"13926","messageId":"43AA75D1.7040009@op5.se","threadId":"2887","inReplyTo":"Pine.LNX.4.63.0512212317400.18684@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git /objects directory created 755 by default?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-12-22T09:45:53Z","receivedAt":"2005-12-22T09:45:53Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Wed, 21 Dec 2005, Junio C Hamano wrote:\n> \n> \n>>Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n>>\n>>\n>>>If you don't use git-shell, because the same machine is used for other \n>>>purposes, it makes sense to introduce\n>>>\n>>>\t[core]\n>>>\t\tumask = 0002\n>>\n>>I agree the setting should not be limited to git-shell, but I do\n>>not think setting \"umask\" from git configuration is the right\n>>way either.  For files and directories under $GIT_DIR, maybe\n>>imposing the policy git configuration file has is OK, but I\n>>think honoring the user's umask is the right thing for working\n>>tree files.\n> \n> \n> As we worked out in another thread, you should not have a working \n> directory when you write-share the repository.\n> \n\nWhich thread was that? I see no particular problem with having a working \ndirectory in a write-shared repo. The same care has to be taken there as \neverywhere (pull before push), but that's nothing new.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"13928","messageId":"81b0412b0512220211o74f7f533j11b8e48311b61ec2@mail.gmail.com","threadId":"2887","inReplyTo":"Pine.LNX.4.63.0512212317400.18684@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git /objects directory created 755 by default?","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2005-12-22T10:11:25Z","receivedAt":"2005-12-22T10:11:25Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 12/21/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> > >\n> > >     [core]\n> > >             umask = 0002\n> So, I tend to say: use core.umask only in shared setups (in which you\n> should not checkout files unless you know exactly what you are doing).\n\nMay be \"shell.umask\" or \"shared.umask\" ?\n"},{"id":"13932","messageId":"Pine.LNX.4.63.0512221220220.7112@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2887","inReplyTo":"43AA75D1.7040009@op5.se","subject":"Re: git /objects directory created 755 by default?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-12-22T11:27:09Z","receivedAt":"2005-12-22T11:27:09Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 22 Dec 2005, Andreas Ericsson wrote:\n\n> Johannes Schindelin wrote:\n> > Hi,\n> > \n> > On Wed, 21 Dec 2005, Junio C Hamano wrote:\n> > \n> > \n> > > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> > > \n> > > \n> > > > If you don't use git-shell, because the same machine is used for other\n> > > > purposes, it makes sense to introduce\n> > > > \n> > > > \t[core]\n> > > > \t\tumask = 0002\n> > > \n> > > I agree the setting should not be limited to git-shell, but I do\n> > > not think setting \"umask\" from git configuration is the right\n> > > way either.  For files and directories under $GIT_DIR, maybe\n> > > imposing the policy git configuration file has is OK, but I\n> > > think honoring the user's umask is the right thing for working\n> > > tree files.\n> > \n> > \n> > As we worked out in another thread, you should not have a working directory\n> > when you write-share the repository.\n> > \n> \n> Which thread was that? I see no particular problem with having a working\n> directory in a write-shared repo. The same care has to be taken there as\n> everywhere (pull before push), but that's nothing new.\n\nIt was the thread \"How to set up a shared repository\".\n\nOkay, so there you are. You have a write-shared repository with the HEAD \nchecked out. Somebody wants to push to that with different credentials \nthan the user who checked out the files. Do you plainly deny updating the \ncurrent HEAD?\n\nIf you do, then you better give the pushing user (pun intended) a way to \nupdate the checked out files. You can do this by (tadaah) setting the \numask to 0002 also for working files.\n\nYes, we could find out exactly where writes happen inside GIT_DIR and plug \nin shared.umask which is only applied in these cases, but I am totally \nunconvinced that this is worth the hassle. In my cases, I am perfectly \nhelped by a umask which is respected throughout git, and the patch is \nsimple enough to be reviewed in 5 minutes.\n\nCiao,\nDscho\n"},{"id":"13933","messageId":"Pine.LNX.4.63.0512221227190.7112@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2887","inReplyTo":"81b0412b0512220211o74f7f533j11b8e48311b61ec2@mail.gmail.com","subject":"Re: git /objects directory created 755 by default?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-12-22T11:35:02Z","receivedAt":"2005-12-22T11:35:02Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 22 Dec 2005, Alex Riesen wrote:\n\n> On 12/21/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> > > >\n> > > >     [core]\n> > > >             umask = 0002\n> > So, I tend to say: use core.umask only in shared setups (in which you\n> > should not checkout files unless you know exactly what you are doing).\n> \n> May be \"shell.umask\" or \"shared.umask\" ?\n\nWhat would shell.umask do? Be set only when git-shell is called? Then you \nbetter have the policy to access that particular repository *only* via \ngit-shell. Voila, it is the same effect as of core.umask.\n\nWhat would shared.umask do? Be set only when writing to GIT_DIR? This is a \nmajor task, since you have to find out which writes are to the working \ndirectory, which ones go to GIT_DIR.\n\nAnd you have to workout a policy (as I just answered in this thread) how \nto deal with a checked out HEAD where you can't write to the working \ndirectory (or at least modify the checked out files).\n\nThe sanest way I can think of is either to disallow checkout, or to make \nthe files writable to the group. Both methods do fine with core.umask.\n\nNow that I think of it: A third possibility is to disallow pushing to the \nchecked out HEAD. Is this desirable? I think not. The user who works in \nthe working directory exclusively would have to keep track of the \npushed ref herself, instead of the user who pushed the ref. Sounds silly \nto me.\n\nHth,\nDscho\n"},{"id":"13934","messageId":"43AA9BE6.7000601@op5.se","threadId":"2887","inReplyTo":"Pine.LNX.4.63.0512221220220.7112@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git /objects directory created 755 by default?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-12-22T12:28:22Z","receivedAt":"2005-12-22T12:28:22Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Thu, 22 Dec 2005, Andreas Ericsson wrote:\n> \n> \n>>Johannes Schindelin wrote:\n>>\n>>>Hi,\n>>>\n>>>On Wed, 21 Dec 2005, Junio C Hamano wrote:\n>>>\n>>>\n>>>\n>>>>Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n>>>>\n>>>>\n>>>>\n>>>>>If you don't use git-shell, because the same machine is used for other\n>>>>>purposes, it makes sense to introduce\n>>>>>\n>>>>>\t[core]\n>>>>>\t\tumask = 0002\n>>>>\n>>>>I agree the setting should not be limited to git-shell, but I do\n>>>>not think setting \"umask\" from git configuration is the right\n>>>>way either.  For files and directories under $GIT_DIR, maybe\n>>>>imposing the policy git configuration file has is OK, but I\n>>>>think honoring the user's umask is the right thing for working\n>>>>tree files.\n>>>\n>>>\n>>>As we worked out in another thread, you should not have a working directory\n>>>when you write-share the repository.\n>>>\n>>\n>>Which thread was that? I see no particular problem with having a working\n>>directory in a write-shared repo. The same care has to be taken there as\n>>everywhere (pull before push), but that's nothing new.\n> \n> \n> It was the thread \"How to set up a shared repository\".\n> \n> Okay, so there you are. You have a write-shared repository with the HEAD \n> checked out. Somebody wants to push to that with different credentials \n> than the user who checked out the files. Do you plainly deny updating the \n> current HEAD?\n> \n> If you do, then you better give the pushing user (pun intended) a way to \n> update the checked out files. You can do this by (tadaah) setting the \n> umask to 0002 also for working files.\n> \n\nAhh. Sorry. We use this method a lot, really, but always only for \nrunning gitk and archaeology tools to check newly pushed changes, so the \nwrite-shared repo is only write-shared for remote users, and the local \none never does a commit. It's perhaps a bit of a weird setup, but it \nlets you get an overview faster than gitweb and works well enough with \nsamba. Noted should be that having the repo checked out is merely a \nconvenience thing to let one browse the files at leisure. People know to do\n\tgit checkout -f HEAD\n\nwhenever they want to dig around.\n\n> Yes, we could find out exactly where writes happen inside GIT_DIR and plug \n> in shared.umask which is only applied in these cases, but I am totally \n> unconvinced that this is worth the hassle. In my cases, I am perfectly \n> helped by a umask which is respected throughout git, and the patch is \n> simple enough to be reviewed in 5 minutes.\n> \n\nBut adding\n\n\tumask 002\n\nto /etc/bashrc would do exactly the same thing, so why have it a setting \nfor the repository only? In my experience, most servers used for hosting \ngit repos host *lots* of them (look at master.kernel.org), so a \nserver-wide setting really makes much more sense. If the server admin \ncan't be bothered you can always change $HOME/.bashrc.\n\nSo long as people remember that .bash_profile isn't read for \nnon-interactive shells this should do nicely. If they can't remember \nthat they won't remember adding the setting to the repository either.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"13936","messageId":"Pine.LNX.4.63.0512221530570.18551@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2887","inReplyTo":"43AA9BE6.7000601@op5.se","subject":"Re: git /objects directory created 755 by default?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-12-22T14:37:18Z","receivedAt":"2005-12-22T14:37:18Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 22 Dec 2005, Andreas Ericsson wrote:\n\n> Johannes Schindelin wrote:\n> > \n> > Okay, so there you are. You have a write-shared repository with the HEAD\n> > checked out. Somebody wants to push to that with different credentials than\n> > the user who checked out the files. Do you plainly deny updating the current\n> > HEAD?\n> > \n> > If you do, then you better give the pushing user (pun intended) a way to\n> > update the checked out files. You can do this by (tadaah) setting the umask\n> > to 0002 also for working files.\n> > \n> \n> Ahh. Sorry. We use this method a lot, really, but always only for running gitk\n> and archaeology tools to check newly pushed changes, so the write-shared repo\n> is only write-shared for remote users, and the local one never does a commit.\n> It's perhaps a bit of a weird setup, but it lets you get an overview faster\n> than gitweb and works well enough with samba. Noted should be that having the\n> repo checked out is merely a convenience thing to let one browse the files at\n> leisure. People know to do\n> \tgit checkout -f HEAD\n> \n> whenever they want to dig around.\n\nBetter to do this with a post-update hook, right? You can't forget to \ncheckout this way. *Plus* you can make sure the umask is correct in the \nhook.\n\n> > Yes, we could find out exactly where writes happen inside GIT_DIR and plug\n> > in shared.umask which is only applied in these cases, but I am totally\n> > unconvinced that this is worth the hassle. In my cases, I am perfectly\n> > helped by a umask which is respected throughout git, and the patch is simple\n> > enough to be reviewed in 5 minutes.\n> > \n> \n> But adding\n> \n> \tumask 002\n> \n> to /etc/bashrc would do exactly the same thing, so why have it a setting for\n> the repository only? In my experience, most servers used for hosting git repos\n> host *lots* of them (look at master.kernel.org), so a server-wide setting\n> really makes much more sense. If the server admin can't be bothered you can\n> always change $HOME/.bashrc.\n\nIn my very special setup, it is a server on which you have your personal \nfiles, too. So, setting umask = 0002 globally is not an option.\n\nFurthermore, it just feels wrong to set an option outside of git which is \nmeant *only* for git usage.\n\n> So long as people remember that .bash_profile isn't read for non-interactive\n> shells this should do nicely. If they can't remember that they won't remember\n> adding the setting to the repository either.\n\nProblem is, what if one of your users is a tcsh zealot? Or simply forgot \nto set it. Trouble in China. Also, I simply can not memorize what startup \nscript gets called when.\n\nCiao,\nDscho\n"},{"id":"13937","messageId":"81b0412b0512220638j382252b5l24e1c6b261165bd6@mail.gmail.com","threadId":"2887","inReplyTo":"Pine.LNX.4.63.0512221227190.7112@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git /objects directory created 755 by default?","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2005-12-22T14:38:08Z","receivedAt":"2005-12-22T14:38:08Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 12/22/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> > > > >\n> > > > >     [core]\n> > > > >             umask = 0002\n> > > So, I tend to say: use core.umask only in shared setups (in which you\n> > > should not checkout files unless you know exactly what you are doing).\n> >\n> > May be \"shell.umask\" or \"shared.umask\" ?\n>\n> What would shell.umask do? Be set only when git-shell is called? Then you\n> better have the policy to access that particular repository *only* via\n> git-shell. Voila, it is the same effect as of core.umask.\n\nI mean it to be set only when git-shell called, but with explicit semantics\n(\"for git-shell only\").\n\n> What would shared.umask do? Be set only when writing to GIT_DIR? This is a\n> major task, since you have to find out which writes are to the working\n> directory, which ones go to GIT_DIR.\n\nshared.mask = shell.mask. Just a name to express what it is for\n"},{"id":"13938","messageId":"Pine.LNX.4.63.0512221603490.18668@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2887","inReplyTo":"81b0412b0512220638j382252b5l24e1c6b261165bd6@mail.gmail.com","subject":"Re: git /objects directory created 755 by default?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-12-22T15:09:44Z","receivedAt":"2005-12-22T15:09:44Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 22 Dec 2005, Alex Riesen wrote:\n\n> On 12/22/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> >\n> > What would shell.umask do? Be set only when git-shell is called? Then you\n> > better have the policy to access that particular repository *only* via\n> > git-shell. Voila, it is the same effect as of core.umask.\n> \n> I mean it to be set only when git-shell called, but with explicit semantics\n> (\"for git-shell only\").\n\nBut if somebody writes to the same repository with another umask, say \n0022, you have problems. Example:\n\n- I push -- via ssh/bash -- to the repository. The ref refs/heads/bruchpilot\n  is updated (mode: 0644).\n\n- My colleague pushes -- via ssh/git-shell -- to the repository. When she\n  tries to write refs/heads/bruchpilot, it fails, even if she set the \n  correct umask.\n\nSee what I mean? It makes no sense to allow different umasks on the \nrepository.\n\n> > What would shared.umask do? Be set only when writing to GIT_DIR? This is a\n> > major task, since you have to find out which writes are to the working\n> > directory, which ones go to GIT_DIR.\n> \n> shared.mask = shell.mask. Just a name to express what it is for\n\nYou do mean different umasks for different access methods, don't you? See \nabove why I don't think that makes sense.\n\nCiao,\nDscho\n"},{"id":"13939","messageId":"81b0412b0512220714w7fb1d9c2j95bbe620fd88cf95@mail.gmail.com","threadId":"2887","inReplyTo":"Pine.LNX.4.63.0512221603490.18668@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git /objects directory created 755 by default?","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2005-12-22T15:14:24Z","receivedAt":"2005-12-22T15:14:24Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 12/22/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> > >\n> > > What would shell.umask do? Be set only when git-shell is called? Then you\n> > > better have the policy to access that particular repository *only* via\n> > > git-shell. Voila, it is the same effect as of core.umask.\n> >\n> > I mean it to be set only when git-shell called, but with explicit semantics\n> > (\"for git-shell only\").\n>\n> But if somebody writes to the same repository with another umask, say\n> 0022, you have problems. Example:\n>\n> - I push -- via ssh/bash -- to the repository. The ref refs/heads/bruchpilot\n>   is updated (mode: 0644).\n>\n> - My colleague pushes -- via ssh/git-shell -- to the repository. When she\n>   tries to write refs/heads/bruchpilot, it fails, even if she set the\n>   correct umask.\n>\n> See what I mean? It makes no sense to allow different umasks on the\n> repository.\n\nDoes it make sense to allow different access methods to a shared repository?\n\n> > > What would shared.umask do? Be set only when writing to GIT_DIR? This is a\n> > > major task, since you have to find out which writes are to the working\n> > > directory, which ones go to GIT_DIR.\n> >\n> > shared.mask = shell.mask. Just a name to express what it is for\n>\n> You do mean different umasks for different access methods, don't you? See\n> above why I don't think that makes sense.\n\nNo, just different names for the same access method.\n"},{"id":"13940","messageId":"Pine.LNX.4.63.0512221651160.18945@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2887","inReplyTo":"81b0412b0512220714w7fb1d9c2j95bbe620fd88cf95@mail.gmail.com","subject":"Re: git /objects directory created 755 by default?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-12-22T15:52:01Z","receivedAt":"2005-12-22T15:52:01Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 22 Dec 2005, Alex Riesen wrote:\n\n> Does it make sense to allow different access methods to a shared repository?\n\nMy point is: regardless if you allow different access methods or not, you \nonly need one method to set a repository-wide umask.\n\nCiao,\nDscho\n"},{"id":"13941","messageId":"43AACBE9.7060201@op5.se","threadId":"2887","inReplyTo":"Pine.LNX.4.63.0512221530570.18551@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git /objects directory created 755 by default?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-12-22T15:53:13Z","receivedAt":"2005-12-22T15:53:13Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"\n\nJohannes Schindelin wrote:\n> Hi,\n> \n> On Thu, 22 Dec 2005, Andreas Ericsson wrote:\n> \n> \n>>Johannes Schindelin wrote:\n>>\n>>>Okay, so there you are. You have a write-shared repository with the HEAD\n>>>checked out. Somebody wants to push to that with different credentials than\n>>>the user who checked out the files. Do you plainly deny updating the current\n>>>HEAD?\n>>>\n>>>If you do, then you better give the pushing user (pun intended) a way to\n>>>update the checked out files. You can do this by (tadaah) setting the umask\n>>>to 0002 also for working files.\n>>>\n>>\n>>Ahh. Sorry. We use this method a lot, really, but always only for running gitk\n>>and archaeology tools to check newly pushed changes, so the write-shared repo\n>>is only write-shared for remote users, and the local one never does a commit.\n>>It's perhaps a bit of a weird setup, but it lets you get an overview faster\n>>than gitweb and works well enough with samba. Noted should be that having the\n>>repo checked out is merely a convenience thing to let one browse the files at\n>>leisure. People know to do\n>>\tgit checkout -f HEAD\n>>\n>>whenever they want to dig around.\n> \n> \n> Better to do this with a post-update hook, right? You can't forget to \n> checkout this way. *Plus* you can make sure the umask is correct in the \n> hook.\n> \n\nWhat prevents you from setting umask 002 in the hook? If the files are \nalready checked out with some other (write-denying) umask by some other \nuser it will fail regardless of where the umask comes from.\n\n> \n>>>Yes, we could find out exactly where writes happen inside GIT_DIR and plug\n>>>in shared.umask which is only applied in these cases, but I am totally\n>>>unconvinced that this is worth the hassle. In my cases, I am perfectly\n>>>helped by a umask which is respected throughout git, and the patch is simple\n>>>enough to be reviewed in 5 minutes.\n>>>\n>>\n>>But adding\n>>\n>>\tumask 002\n>>\n>>to /etc/bashrc would do exactly the same thing, so why have it a setting for\n>>the repository only? In my experience, most servers used for hosting git repos\n>>host *lots* of them (look at master.kernel.org), so a server-wide setting\n>>really makes much more sense. If the server admin can't be bothered you can\n>>always change $HOME/.bashrc.\n> \n> \n> In my very special setup, it is a server on which you have your personal \n> files, too. So, setting umask = 0002 globally is not an option.\n> \n\nscp -p preserves the umask you have on your desktop/laptop, so unless \nyou frequently do\n\n\tssh somewhere \"echo 'Gawds, this is an awkward way of editing files' >> \nsomefile\"\n\nyou should be good with the bashrc setting. You can override it from \nbash_profile to make sure you get a safely sane umask when logging in \ninteractively.\n\n> \n>>So long as people remember that .bash_profile isn't read for non-interactive\n>>shells this should do nicely. If they can't remember that they won't remember\n>>adding the setting to the repository either.\n> \n> \n> Problem is, what if one of your users is a tcsh zealot? Or simply forgot \n> to set it. Trouble in China. Also, I simply can not memorize what startup \n> script gets called when.\n> \n\ntcsh zealot? Not familiar with that one. If you're trying to cover every \nangle I think you'll be in for a disappointment though. Users are \nusually fairly ingenious when it comes to finding ways of causing trouble.\n\nAs for forgetting to set it, I was talking about the /etc/bashrc file \nhere. There is a /etc/cshrc as well, although this tcsh zealot shell \nmight ignore it.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"13942","messageId":"Pine.LNX.4.63.0512221700310.18982@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2887","inReplyTo":"43AACBE9.7060201@op5.se","subject":"Re: git /objects directory created 755 by default?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-12-22T16:03:41Z","receivedAt":"2005-12-22T16:03:41Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nthis is getting silly. The problem is: how to setup a shared repository, \ni.e. a repository into which different users can push their updates.\n\nYes, I can work around the fact that git (in its current official version) \ndoes not have an option to make that happen.\n\nIt is just awfully cumbersome. And that is what good software should \nprevent. Especially if it is *that* easy.\n\nHth,\nDscho\n"},{"id":"13944","messageId":"43AAD9D7.1070503@op5.se","threadId":"2887","inReplyTo":"Pine.LNX.4.63.0512221700310.18982@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git /objects directory created 755 by default?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-12-22T16:52:39Z","receivedAt":"2005-12-22T16:52:39Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> this is getting silly. The problem is: how to setup a shared repository, \n> i.e. a repository into which different users can push their updates.\n> \n\nYou're simplifying. Your question was\n\"How can I set up a repository for multiple users to write to without \nsetting a global umask for non-interactive shells?\"\n\nJunio said:\n\"I agree the setting should not be limited to git-shell, but I do\nnot think setting \"umask\" from git configuration is the right\nway either.  For files and directories under $GIT_DIR, maybe\nimposing the policy git configuration file has is OK, but I\nthink honoring the user's umask is the right thing for working\ntree files.\"\n\nwhich I whole-heartedly agree with. I'd be completely furious if a tool \nignored the umask I use for checking out files of a local repository \njust because I happen to do some work at the machine where the repo is \nstored (I imagine this couldn't possibly affect repositories cloned \nremotely, although that would surely have me going ballistic).\n\nYou answered that it would be good for hooks as well, although those can \nset their own umask easily enough (if you forget it there, you'll be \nhastily reminded the first time it breaks, so no real harm done).\n\nThe problem as I see it is to update only the $GIT_DIR files with the \nproper umask (or rather, just the objects/ and refs/ directories, since \n$GIT_DIR/. is never touched after being created and the other are for \nrepo maintainers only).\n\nEnter the nifty git-receive-pack, which does all the writing when a repo \nis being pushed to, unless bypassed from the /git/foo working tree for \nthe /git/foo/.git repository. The latter is already discouraged, so we \nmight as well ignore that. It's also nice because it will never mess \nwith files that are for the repo maintainer only, although hooks can \nofcourse do whatever they like to those files provided the repo \nmaintainer allows it.\n\nNow it's time to go home, but I'll have a patch by tonight unless you \nbeat me to it. :)\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"13946","messageId":"Pine.LNX.4.63.0512221823460.19925@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2887","inReplyTo":"43AAD9D7.1070503@op5.se","subject":"Re: git /objects directory created 755 by default?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-12-22T17:31:39Z","receivedAt":"2005-12-22T17:31:39Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 22 Dec 2005, Andreas Ericsson wrote:\n\n> Johannes Schindelin wrote:\n> > Hi,\n> > \n> > this is getting silly. The problem is: how to setup a shared repository,\n> > i.e. a repository into which different users can push their updates.\n> > \n> \n> You're simplifying. Your question was\n> \"How can I set up a repository for multiple users to write to without setting\n> a global umask for non-interactive shells?\"\n\nNo, I am not. My question really was: how do I setup a shared repository?\n\nNow, my intention was to make it as easy as possible.\n\n> Junio said:\n> \"I agree the setting should not be limited to git-shell, but I do\n> not think setting \"umask\" from git configuration is the right\n> way either.  For files and directories under $GIT_DIR, maybe\n> imposing the policy git configuration file has is OK, but I\n> think honoring the user's umask is the right thing for working\n> tree files.\"\n\nIMHO Junio is wrong here. If the repository is write-shared, then the \nworking directory should be write-shared as well (or checkout should be \nDENIED), else you get all kinds of problems.\n\n> which I whole-heartedly agree with. I'd be completely furious if a tool\n> ignored the umask I use for checking out files of a local repository just\n> because I happen to do some work at the machine where the repo is stored (I\n> imagine this couldn't possibly affect repositories cloned remotely, although\n> that would surely have me going ballistic).\n\nI do not understand what you mean by \"repositories cloned remotely\".\n\nAnd if you really are working in the working directory of the shared \nrepository, and a user (I know I would do it just to annoy you) pushes a \nnew HEAD while you have modified files, you deserve what you get: a \ncomplete mess.\n\nAs for setting the umask only when writing into $GIT_DIR: unless somebody \nconvinces me that it solves a problem, this is unncessary work.\n\nYou are free to ignore my warnings and my patch, I got no problem with \nthat.\n\nYou are also free to wait for users to complain why this and that breaks, \nor why setting up a shared repository has to be hard, and apply my patch \nthen.\n\nHth,\nDscho\n"},{"id":"13950","messageId":"7vwthxlzai.fsf@assigned-by-dhcp.cox.net","threadId":"2887","inReplyTo":"43AAD9D7.1070503@op5.se","subject":"Re: git /objects directory created 755 by default?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-22T19:14:29Z","receivedAt":"2005-12-22T19:14:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson <ae@op5.se> writes:\n\n> Junio said:\n> \"I agree the setting should not be limited to git-shell, but I do\n> not think setting \"umask\" from git configuration is the right\n> way either.  For files and directories under $GIT_DIR, maybe\n> imposing the policy git configuration file has is OK, but I\n> think honoring the user's umask is the right thing for working\n> tree files.\"\n\nI think this needs qualifying.\n\nWhen we talk about \"CVS-style shared repository\", we know what\nit is -- there is no such thing as \"*the* working tree\nassociated with the repository\" and there is no room for\ndisagreement.\n\nThe workflow your shared repository implies is that there is an\nassociated working tree with that repository, and the working\ntree should allow updates by participants who are allowed to\ncreate new things in .git/objects and update .git/refs/.  If you\nassume that is the only valid use case for non-naked shared\nrepository, then what I said above is not needed.  It does not\nmake any sense to have anything stricter than 007 as umask in\nsuch a case.  But is it the only valid use case?\n\nI could give each of the gitsters I trust an git-shell account\non my private machine and prepare refs/heads/rcpt/js branch for\nyou and refs/heads/rcpt/ae for Andreas to push into (I would use\nCarl's per branch push policy to make sure those \"receipt\nbranches\" are the only ones you guys can push into if I did so).\n\nThen instead of sending \"I now have this public repository and\nhave goodies for git improvement; please pull\" e-mail to me, you\ncould push into your branch.  I will keep working on master (and\nmy own topic branches), with whatever branch checked out in the\nworking tree, and merge from those rcpt branches at my leisure.\nYou guys are not allowed to touch my working tree, though.\n\nIn such a scenario, there is no reason to forbid me from\napplying umask 022 to my working tree files, even though making\nsure that fan-out directories of .git/objects/ *I* lazily create\ncan be writable by you is essential.\n\nI have a feeling that it might be good enough to modify\nsafe_create_leading_directories() to chmod(0777) after creating\na new directory under .git/ (or limit it to .git/objects/).  The\nrepository administrator can restrict things further by chmod\n0770 .git/ as needed.\n"},{"id":"13953","messageId":"Pine.LNX.4.63.0512222022510.31591@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2887","inReplyTo":"7vwthxlzai.fsf@assigned-by-dhcp.cox.net","subject":"Re: git /objects directory created 755 by default?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-12-22T19:28:45Z","receivedAt":"2005-12-22T19:28:45Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 22 Dec 2005, Junio C Hamano wrote:\n\n> When we talk about \"CVS-style shared repository\", we know what\n> it is -- there is no such thing as \"*the* working tree\n> associated with the repository\" and there is no room for\n> disagreement.\n\nThis is what I mean by shared repository.\n\n> I could give each of the gitsters I trust an git-shell account\n> on my private machine and prepare refs/heads/rcpt/js branch for\n> you and refs/heads/rcpt/ae for Andreas to push into (I would use\n> Carl's per branch push policy to make sure those \"receipt\n> branches\" are the only ones you guys can push into if I did so).\n> \n> Then instead of sending \"I now have this public repository and\n> have goodies for git improvement; please pull\" e-mail to me, you\n> could push into your branch.  I will keep working on master (and\n> my own topic branches), with whatever branch checked out in the\n> working tree, and merge from those rcpt branches at my leisure.\n> You guys are not allowed to touch my working tree, though.\n\nThis has some merit, for example, when some of the contributors have no \npublic repository.\n\n> In such a scenario, there is no reason to forbid me from\n> applying umask 022 to my working tree files, even though making\n> sure that fan-out directories of .git/objects/ *I* lazily create\n> can be writable by you is essential.\n> \n> I have a feeling that it might be good enough to modify\n> safe_create_leading_directories() to chmod(0777) after creating\n> a new directory under .git/ (or limit it to .git/objects/).  The\n> repository administrator can restrict things further by chmod\n> 0770 .git/ as needed.\n\nAnd then somebody comes along and allows world access by chmod(0775) and \ndoes not realize that *everybody* can delete packs, objects and what-nots \nin GIT_DIR.\n\nGiven the complexity we are talking about, and the needs which are not at \nall that complicated, why not just go with core.umask until somebody \n*needs* core.repositoryumask?\n\nCiao,\nDscho\n"},{"id":"13955","messageId":"7v3bkkkhwb.fsf@assigned-by-dhcp.cox.net","threadId":"2887","inReplyTo":"Pine.LNX.4.63.0512222022510.31591@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git /objects directory created 755 by default?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-22T20:15:32Z","receivedAt":"2005-12-22T20:15:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> And then somebody comes along and allows world access by chmod(0775) and \n> does not realize that *everybody* can delete packs, objects and what-nots \n> in GIT_DIR.\n\nThat somebody has to be somebody who owns .git directory not\njust a group member, so that is not a serious objection either,\nbut you need to realize I was joking with 0777 -- a saner\ndefault would obviously be 0775.  Otherwise you would not be\nable to server it from gitweb safely -- http server is typically\nnot a group member.\n\n> Given the complexity we are talking about, and the needs which are not at \n> all that complicated, why not just go with core.umask until somebody \n> *needs* core.repositoryumask?\n\nI am afraid that is going backwards.  Nobody *needs* core.umask\neither, but we are still talking about this.  That is because\nyou wanted to make things easier for people, and I agree with\nyou that it would be nicer if we did not require people set\numask to sane values suitable for group work themselves, but\nsomehow we did that automatically for them.  The longer I think\nabout it, however, the more I feel this is a lost cause.\n\nEarlier, I suggested git-shell one-liner, only because I thought\ngit-shell users (or administrators that support git-shell users)\nmay not have any way to set the umask to sane values themselves,\nbut I think that should also be doable by telling sshd what the\ninitial umask of the users should be.  And that was where this\numask discussion was started, but I think not touching umask at\nall is the right direction.\n\nYour core.umask would make sure the .git/objects/ directory\nwould be suitable for other members, but git is not the only\ntool the people would use in the working tree.  To work well\nwith an editor that does not overwrite an existing file but does\ncreat/rename upon saving would require you to have a sane umask\nif the user adopts your \"shared working tree writable by all\nmembers\" workflow.  Running \"make\" in the working tree would\nleave object files, worse yet in a temporary build directory\nmake created, with permission bits masked with your umask,\nmaking it imposible to run \"make clean\" for other members.\n\nRegardless of where and how people come from to work in the\nworking tree, they need to set umask appropriately anyway.\n\nThe only possible issue is one umask might not be sufficient,\nbut unfortunately you can have only one umask at a time.  The\nexample of \"receiption branches\" is not a shared repository for\nme in the strict sense, but allows for you to push into.  I\ncannot work with umask 022 in such a repository even if I wanted\nto have files in the working tree honor tighter umask.  To deal\nalso with such cases, not mucking with umask but solving the\nproblem in a more direct way may make more sense -- namely we\nshould be able to say \"such and such things under .git/ in this\nrepository must be ug+rw regardless of user's umask\".\n"},{"id":"13956","messageId":"Pine.LNX.4.63.0512222122300.355@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2887","inReplyTo":"7v3bkkkhwb.fsf@assigned-by-dhcp.cox.net","subject":"Re: git /objects directory created 755 by default?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-12-22T20:27:09Z","receivedAt":"2005-12-22T20:27:09Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 22 Dec 2005, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > And then somebody comes along and allows world access by chmod(0775) and \n> > does not realize that *everybody* can delete packs, objects and what-nots \n> > in GIT_DIR.\n> \n> That somebody has to be somebody who owns .git directory not\n> just a group member, so that is not a serious objection either,\n> but you need to realize I was joking with 0777 -- a saner\n> default would obviously be 0775.  Otherwise you would not be\n> able to server it from gitweb safely -- http server is typically\n> not a group member.\n\nI was talking about somebody who has only one server for everything: mail, \nweb and git. So this somebody would be the owner of .git.\n\n> > Given the complexity we are talking about, and the needs which are not at \n> > all that complicated, why not just go with core.umask until somebody \n> > *needs* core.repositoryumask?\n> \n> I am afraid that is going backwards.  Nobody *needs* core.umask\n> either, but we are still talking about this.\n\nWell, I do.\n\n> Your core.umask would make sure the .git/objects/ directory\n> would be suitable for other members, but git is not the only\n> tool the people would use in the working tree.  To work well\n> with an editor that does not overwrite an existing file but does\n> creat/rename upon saving would require you to have a sane umask\n> if the user adopts your \"shared working tree writable by all\n> members\" workflow.  Running \"make\" in the working tree would\n> leave object files, worse yet in a temporary build directory\n> make created, with permission bits masked with your umask,\n> making it imposible to run \"make clean\" for other members.\n\nHmm. That is convincing.\n\n> we should be able to say \"such and such things under .git/ in this \n> repository must be ug+rw regardless of user's umask\".\n\nYes, I tried to avoid that.\n\nCiao,\nDscho\n"},{"id":"13972","messageId":"7vslsllz17.fsf@totally-fudged-out-message-id","threadId":"2887","inReplyTo":"43AA9BE6.7000601@op5.se","subject":"Re: git /objects directory created 755 by default?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-23T04:19:50Z","receivedAt":"2005-12-23T04:19:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson <ae@op5.se> writes:\n\n> Ahh. Sorry. We use this method a lot, really, but always only for \n> running gitk and archaeology tools to check newly pushed changes, so the \n> write-shared repo is only write-shared for remote users, and the local \n> one never does a commit.\n\nDo you need a working tree to run gitk?\n"},{"id":"13980","messageId":"43ABE899.6030002@op5.se","threadId":"2887","inReplyTo":"7vslsllz17.fsf@totally-fudged-out-message-id","subject":"Re: git /objects directory created 755 by default?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-12-23T12:07:53Z","receivedAt":"2005-12-23T12:07:53Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Andreas Ericsson <ae@op5.se> writes:\n> \n> \n>>Ahh. Sorry. We use this method a lot, really, but always only for \n>>running gitk and archaeology tools to check newly pushed changes, so the \n>>write-shared repo is only write-shared for remote users, and the local \n>>one never does a commit.\n> \n> \n> Do you need a working tree to run gitk?\n> \n\nNo, but it makes for a nice shorthand, especially since most of our \nprojects are riddled with sub-repos.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"}]}