{"thread":{"id":"32115","subject":"git init shared=group with a subdir","startedAt":"2012-11-14T20:00:03Z","lastAt":"2012-11-14T20:29:45Z","messageCount":2,"participants":["petesea@bigfoot.com","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"203219","messageId":"alpine.OSX.2.00.1211141107180.737@nikto-air","threadId":"32115","inReplyTo":null,"subject":"git init shared=group with a subdir","fromName":"","fromEmail":"petesea@bigfoot.com","sentAt":"2012-11-14T20:00:03Z","receivedAt":"2012-11-14T20:00:03Z","isPatch":false,"sender":{"key":"petesea@bigfoot.com","avatar":null},"body":"I believe there may be a bug when initializing a new repository relating \nto the directory permissions when the --shared=group option is used and \nthe repository is within a sub-directory.\n\nThe following will create the \"test.git\" directory with 2775 permissions \n(which is as expected):\n\n   $ ls -ld test.git\n   ls: cannot access test.git: No such file or directory\n   $ git init --bare --shared=group test.git\n   Initialized empty shared Git repository in /tmp/test.git/\n   $ ls -ld test.git\n   drwxrwsr-x 7 pete users 4096 2012-11-14 11:15 test.git\n\nThis following will also create the \"test.git\" directory with 2775 \npermissions, BUT the \"subdir\" directory ends up with 755 permissions:\n\n   $ ls -ld subdir\n   ls: cannot access subdir: No such file or directory\n   $ git init --bare --shared=group subdir/test.git\n   Initialized empty shared Git repository in /tmp/subdir/test.git/\n   $ ls -ld subdir subdir/test.git\n   drwxr-xr-x 3 pete users 4096 2012-11-14 11:16 subdir\n   drwxrwsr-x 7 pete users 4096 2012-11-14 11:16 subdir/test.git\n\nAssuming the \"subdir\" directory doesn't already exist and is created by \nthe \"git init\" command AND the --shared=group option is used, then \nshouldn't the \"subdir\" directory also have 2775 permissions?\n"},{"id":"203222","messageId":"7vr4nw9bd2.fsf@alter.siamese.dyndns.org","threadId":"32115","inReplyTo":"alpine.OSX.2.00.1211141107180.737@nikto-air","subject":"Re: git init shared=group with a subdir","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-11-14T20:29:45Z","receivedAt":"2012-11-14T20:29:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"petesea@bigfoot.com writes:\n\n>   $ ls -ld subdir\n>   ls: cannot access subdir: No such file or directory\n>   $ git init --bare --shared=group subdir/test.git\n>   Initialized empty shared Git repository in /tmp/subdir/test.git/\n>   $ ls -ld subdir subdir/test.git\n>   drwxr-xr-x 3 pete users 4096 2012-11-14 11:16 subdir\n>   drwxrwsr-x 7 pete users 4096 2012-11-14 11:16 subdir/test.git\n>\n> Assuming the \"subdir\" directory doesn't already exist and is created\n> by the \"git init\" command AND the --shared=group option is used, then\n> shouldn't the \"subdir\" directory also have 2775 permissions?\n\nPeople who access this \"test.git\" does not need to be able to write\ninto subdir/foobar, so the lack of w bit for the group is perfectly\nfine, no?  Depending on to whom you would want to expose things\nother than \"test.git\" in \"subdir\", the desirable set of the\npermission bits on \"subdir\" itself would be different, but the \"git\ninit\" command line does not give us enough information to infer what\nexact mode is needed.\n\nAt least we should give r-x to the parent directories for the\nclasses of users to whom we give rwx to the repository itself.  In\nyour example, since we give rwx to user=pete and group=users on\n\"test.git\", \"subdir\" should have r-x (or better) for user=pete and\ngroup=users, so that result happens to be correct.\n\nBut I do not think we did the right thing by design but it turned\nout to be correct by accident.  If your umask were 077 or something\ntight, I suspect that we end up creating \"subdir\" with \"rwx------\",\nand group members wouldn't be able to access \"test.git\".  We may\nwant to loosen it down to \"rwxr-x---\" in such a case, but doing so\nunconditionally risks exposing things inside \"subdir\" other than\n\"test.git\" to your group members, and worse yet, we would be doing\nso without telling the user.  If your umask is set to a tight value,\nit is likely that you did so on purpose, and it is debatable if it\nis a good thing to do.  It is safer to create these leading\ndirectories like \"subdir\" honoring the umask, give the user a chance\nto make sure that other things in \"subdir\" can be exposed to people\nwho have access to \"test.git\", and let the user handle the\npermission (perhaps running \"chmod g+rx subdir\" as necessary).  And\nthat is the behaviour you are observing, I think.\n"}]}