From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Schindelin Subject: Re: Unable to create temporary file '/var/git/tmv3-target-overlay.git/shallow_Un8ZOR': Permission denied Date: Sat, 19 Sep 2015 09:13:23 +0200 Organization: gmx Message-ID: References: <1440157010.1759.83.camel@transmode.se> <1442245035.10125.18.camel@transmode.se> <1442508864.21964.26.camel@transmode.se> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Joakim Tjernlund , git@vger.kernel.org To: Duy Nguyen X-From: git-owner@vger.kernel.org Sat Sep 19 09:13:34 2015 Return-path: Envelope-to: gcvg-git-2@plane.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZdCKy-0003uZ-V2 for gcvg-git-2@plane.gmane.org; Sat, 19 Sep 2015 09:13:33 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753848AbbISHN2 (ORCPT ); Sat, 19 Sep 2015 03:13:28 -0400 Received: from mout.gmx.net ([212.227.15.18]:55464 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751842AbbISHN1 (ORCPT ); Sat, 19 Sep 2015 03:13:27 -0400 Received: from dscho.org ([87.106.4.80]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M4002-1Yn9kN0Jd4-00rZFn; Sat, 19 Sep 2015 09:13:25 +0200 In-Reply-To: X-Sender: johannes.schindelin@gmx.de User-Agent: Roundcube Webmail/1.1.2 X-Provags-ID: V03:K0:xrqYVjp2E2j8WbjY+AJi5IXAs8BqPrMBotXH1SbJr4+XW9yEPE3 VrhDprDDPx29+2BDHZlHb5QoVEePkDxiD8FrTFIIi/Ne345AaDpwlPXaQzoNx/a/RVkkAlX rQ9NnyZhJuDEw9b+qdmL4Y9F/QjdHgX941Sp2quT8e+OdJSee9SfamJAJcznvHdeLsn+gyU pLLgFm2pa7y4etyt5vBIw== X-UI-Out-Filterresults: notjunk:1;V01:K0:M1JCNaUq/h0=:Kints/m8iKN0ExcHrGU+HE 69H2RgAveeK3C347khZqjXCkQLUyqdU5hz36LryeKWymoCRVDlB0Xw/BgVdbfpWSQ8vyvAbYh uPeVBBn95fXHVhe0PAI5XYPdn57t4C0BW3BdjiiBvvuUtMmpJzcl4FM8KkryzR6oqR0LVXvRL NWRPXh1/eL1DV2ldF0XVmzMITI+zuQ0WBlBGRzlSUKoSDvkFgK1WzLkQ9sPNgdzI7A5MiRYAR 6prjyOUZJ2a5M+4Ey+iGyCTBdQ/1NXEQHWfpyd9Tim5HqI+1KDn2RmhbZ+lJNvRtoqEDcoSeZ ITZT6f//k98ZtQ6tKtXFo7Q3EzqeEbk7HM2qOvzJQFDUwjXZnHvLZhF5qJUUYW7HEYfm8gbaG fem8P0j0m5S7LQdPMDqxcLpCLYHYpIY3X3FEkxB2gH9c3XnDxRPpP6Sg+yfJNtfFydM+oRiy3 6V6TOyyPjuGGVkuwAYFTAwoY9910oC2HxRK1ZwVvj+64VhP+PXNo2Lfssp/TmEogbDrDz0iak J7D0F4xakpaWHL3t0ndDJbssSODVH7TjPlNAPvr8+//kopQlBsSIfLKUFuhtAHlmRvkwnAI/O F2k55t+T+HvI6NyOkN4SAVs7NNk2MG6HHpsU4n+mhjYllLYYIR2JiTeG20/OMo7mg9c962hur tZ9UUOVDi2Fpyg6urrAlz1WxB2PcIWJLtRxcmZSQpuT+5XYuCInhww8GY2iZmvwOFXoR2UHsl IWUaeeu4ECxG4DjDTMwcfHccPk5yANzHlbh6wA== Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Hi Duy, On 2015-09-19 04:21, Duy Nguyen wrote: > On Thu, Sep 17, 2015 at 11:54 PM, Joakim Tjernlund > wrote: >> On Thu, 2015-09-17 at 20:18 +0700, Duy Nguyen wrote: >>> On Mon, Sep 14, 2015 at 10:37 PM, Joakim Tjernlund >>> wrote: >>> > On Mon, 2015-08-31 at 16:56 +0700, Duy Nguyen wrote: >>> > > On Fri, Aug 21, 2015 at 6:36 PM, Joakim Tjernlund >>> > > wrote: >>> > > > I cannot push: >>> > > > # > git push origin >>> > > > Login for jocke@git.transmode.se >>> > > > Password: >>> > > > Counting objects: 7, done. >>> > > > Delta compression using up to 4 threads. >>> > > > Compressing objects: 100% (7/7), done. >>> > > > Writing objects: 100% (7/7), 13.73 KiB | 0 bytes/s, done. >>> > > > Total 7 (delta 4), reused 0 (delta 0) >>> > > > fatal: Unable to create temporary file '/var/git/tmv3-target-overlay.git/shallow_Un8ZOR': Permission >>> > > > denied > > I'm about to do it, but now I'm not sure if I should move > shallow_XXXXXX out of $GIT_DIR. It will not be the only command that > may write to $GIT_DIR. "git gc --auto" (which can be triggered at the > server side at push time) can write $GIT_DIR/gc.pid (and soon, > gc.log). Even if you disable gc --auto and run it periodically (with > cron or something), it will write gc.pid. > > Is it really necessary to remove write access in $GIT_DIR? Do we (git > devs) have some guidelines about things in $GIT_DIR? IMO it makes little sense to remove write access from users who you want to push. They need to write objects to the directory, after all, and update refs. This problem sounds more like the doing of an overzealous sysadmin to me than a careful one who researched diligently what locations require write access for the intended operations. Personally, I see little sense in bending over to try to support such an intentionally tampered setup. Ciao, Dscho