{"thread":{"id":"32326","subject":"directory permissions on AFS","startedAt":"2012-12-12T23:39:30Z","lastAt":"2012-12-13T00:17:28Z","messageCount":2,"participants":["Jaime Frey","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"204809","messageId":"0A6FA42F-986D-4C3C-BC50-9A7C0494C703@cs.wisc.edu","threadId":"32326","inReplyTo":null,"subject":"directory permissions on AFS","fromName":"Jaime Frey","fromEmail":"jfrey@cs.wisc.edu","sentAt":"2012-12-12T23:39:30Z","receivedAt":"2012-12-12T23:39:30Z","isPatch":false,"sender":{"key":"jfrey@cs.wisc.edu","avatar":null},"body":"Hi,\n\nWe have a shared bare git repository on AFS, which our developers\npull from and push to from their local repositories. Some developers\naccess the bare repository directly over AFS and others use ssh.\nEvery couple of months, all of the two-character directories under\nthe objects directory disappear. Afterwards, most pushes fail with an\nerror like this:\n\nerror: unable to create temporary sha1 filename ./objects/fb:\nPermission denied\n\nStracing git revealed that it successfully recreated the ./objects/fb \nand then failed to chmod() it. It failed because it tried to set the\nS_ISGID bit, which mere mortals cannot do on AFS. Manually recreating \nall of these directories solves the problem. \n\nI took a quick look at the git source and it appears git always tries \nto set the S_ISGID on a new directory if core.sharedrepository is \nenabled in the config. I don't know what other effects would result  \nfrom setting core.sharedrepository to 0.\n\nWould it be feasible to allow the setting of S_ISGID to disabled,\napart from modifying core.sharedrepository? Possibly a new config\nparameter or detecting if the directory is on AFS?\n\n -- Jaime Frey\n"},{"id":"204813","messageId":"7vd2ye24br.fsf@alter.siamese.dyndns.org","threadId":"32326","inReplyTo":"0A6FA42F-986D-4C3C-BC50-9A7C0494C703@cs.wisc.edu","subject":"Re: directory permissions on AFS","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-13T00:17:28Z","receivedAt":"2012-12-13T00:17:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jaime Frey <jfrey@cs.wisc.edu> writes:\n\n> Stracing git revealed that it successfully recreated the ./objects/fb \n> and then failed to chmod() it. It failed because it tried to set the\n> S_ISGID bit, which mere mortals cannot do on AFS. Manually recreating \n> all of these directories solves the problem. \n\nWe fix directory permissions after creating any directory under .git\nwith the same code, so that in a repository shared by group, new\nsubdirectories created by a random somebody who belongs to that\ngroup will belong to that group (we also chmod to g+wx in case such\na random somebody has overly strict umask).  Instead of running\nchown(2) on every new file created by us, we let the filesystem to\ntake care of it by telling the directories we create that new files\nin them should inherit their group ownership.\n\nWhat we were worried about back when we decided to use S_ISGID was a\nscenario like this:\n\n * A repository is shared by group \"src\".\n\n * A user belongs to the group \"src\".  That group may or may not be\n   his primary group (i.e. \"mkdir foo\" done at random place by him\n   may not belong to the \"src\" group).\n\n * The user attempts to create a new branch \"foo/bar\" by pushing\n   from outside.  There is no other branch whose name is\n   \"foo/anything\" when this happens.\n\n * An equivalent of \"mkdir -p .git/refs/heads/foo\" needs to be done\n   before an equivalent of \"echo $sha >.git/refs/heads/foo/bar\"\n   happens to accept this push.  We want \"foo\" and \"bar\" to belong\n   to \"src\" group and they get appropriate permission bits suitable\n   to be accessed by the members of the \"src\" group.\n\nThe story is the same for loose objects and their fan-out directory.\nStoring a commit object fb/012345... may need to create the leading\nfan-out \".git/objects/fb\" and we want that directory and any future\nfiles created in it to belong to the \"src\" group.\n\nAny alternative implementation that achieves the same result that\nworks on AFS can be substituted with the current code, or made\nconditionally activated on AFS.\n"}]}