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: Thu, 24 Sep 2015 00:48:51 +0200 Organization: gmx Message-ID: <815b23cb50fa299d5a70b99f6ff04225@dscho.org> References: <1440157010.1759.83.camel@transmode.se> <1442245035.10125.18.camel@transmode.se> <1442508864.21964.26.camel@transmode.se> <1442855328.29498.30.camel@transmode.se> <37ca95b3fef79e348fb5ba68cd21c590@dscho.org> <1442955525.29498.94.camel@transmode.se> <5f56381a3cf5a5ccf6a1e4e3ea48f516@dscho.org> <1443040900.29498.119.camel@transmode.se> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: git@vger.kernel.org, gitster@pobox.com, pclouds@gmail.com To: Joakim Tjernlund X-From: git-owner@vger.kernel.org Thu Sep 24 00:49:03 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 1ZesqU-0000q6-Op for gcvg-git-2@plane.gmane.org; Thu, 24 Sep 2015 00:49:03 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755450AbbIWWs6 (ORCPT ); Wed, 23 Sep 2015 18:48:58 -0400 Received: from mout.gmx.net ([212.227.15.19]:55249 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754840AbbIWWs5 (ORCPT ); Wed, 23 Sep 2015 18:48:57 -0400 Received: from dscho.org ([87.106.4.80]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LmrUq-1aLvII01Eq-00h3kK; Thu, 24 Sep 2015 00:48:54 +0200 In-Reply-To: <1443040900.29498.119.camel@transmode.se> X-Sender: johannes.schindelin@gmx.de User-Agent: Roundcube Webmail/1.1.2 X-Provags-ID: V03:K0:l552GQcbFXdqInKIO8ss6RnIY1dwoPLhOTE7yDPa9dXlmcjch0d n2JdHkkH7aHxOC7hNV/M5CxYjnLlte2FBvX+Yx6oFaPrf7JD4t5E+VgD4leHP0uG7SW3pma 5jTTP1Ypk+ub3mPCLdZ0GjM1hYg8RAtN0wMTYOJnpAi0p0bdIzK7Aa/VEm53TLAdX8ZkfIC gvlcDwE9KbvJWzb9emsNg== X-UI-Out-Filterresults: notjunk:1;V01:K0:K6FLw0W+RHE=:8tmOKJhFzELhpwwAJpQgNJ TLY+OfNiUmP9o9PbE7EmA8Y4etC72GN6oWN+MZiqzP1wwpgOVGKqalzGGB1HImv9EGMmLzdJL Q3pPRwH4t0UcjtYZf5DW6pJIocVavqbQ9OltmUJWQqFIMZe8Zl8rauuR7joBRGrRkdbWYjKkk qhqMWTp0CNvGinHl7yy0tZQE8vCg+Od2By1gRxnnWz34ZpSfZM6DQPWgtN4MBXW04aXlT4OYU vXllgXo5zgXiPCvEj0NK6LQ3vKtF6WhU200SR2RVWhvsuRZfi7G48VA72eFIE4/QtHNWP+Aep USRrcMfEiDfSfGvLlI2Ly5C6BNcwbrZXa+8ZQFn3OQt65dVJerCFiOROtwZ31/G5msM9IgKxX 28YoIZT+sLM1z0Dlsc5R8r1sSOhm91rRnHaMVsE4oFe3ZgBAow4kZjHhCQHPmm73IG8vADhdX wPD3sOYRwAGXuBqbhf9AawrjFMRRoyfxeqCtojKyfHF55AhzhfsvBqWil8wNSYXc3/c8IOrSi OcPt5XX/bPDHJ26tWhnxm3wHxuKtZNQrLjfejDs6/nLrUNTOg5nJr89aO25DmWNPkKmMuQkdh WtAwcJEcnE4eHRX/4bY1BVY6QvpRiFHzILIVZatBGUmYsaCuD6kdFoXAZrCGkM7D9FehYPdnr IHnaOiCzuQtIwNhcVyf7in4uzTBZZkl93bW5JvokCsBp9yR+Swv6y5Y+3X42NW2/IRm/zcLwi DK6KUFzQ/1QSPa54+xt4Mj6evhnqY4f1sFmGmQ== Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Hi Joakim, On 2015-09-23 22:41, Joakim Tjernlund wrote: > On Wed, 2015-09-23 at 13:10 +0200, Johannes Schindelin wrote: >> >> On 2015-09-22 22:58, Joakim Tjernlund wrote: >> > On Tue, 2015-09-22 at 22:00 +0200, Johannes Schindelin wrote: >> > > >> > > The reason should be easy to understand: Git's concept is based on the idea that you have full control >> > > over >> > > your repository. Other repositories you might only have read access. >> > >> > Yes and some repos I only have partial write access to(config, hooks >> > etc. might be readonly) >> >> The partial write access idea is definitely not part of the original idea of Git, and your use case is >> actually the first I heard of. > > Ouch, that cannot be so?? Yes, it can be so. In fat, it is so. Please note that I *did* encounter valid scenarios where some operations might not be desirable (and therefore need to be prevented). One such scenario (maybe even the first one) was to prevent non-fast-forward pushes. But you will certainly agree that this cannot be prevented by mere file system permission: they are not fine-grained enough. So we introduced a config option -- because in contrast to file system permissions, Git *does* have the means to enforce that rule. So it all comes back to the point I made earlier, and that I really would like you to understand: Git's concepts do not align well with file system permissions. Not well at all, in fact. So the method of choice is indeed what you called that "big axe" which is not such a big axe after all. You just need to set up an SSH server and define very clearly in the hooks what you consider permissible. Yep, that's a bit of work, but it is less work than would be required of Git to bend it so the same could be done via file system permissions. And stay that way. Now, it might be possible for some operations, to *make* Git align with that permission system. But that sounds more and more like the desired changes would require Git developers to put in a lot of work in favor of others being able to avoid work, just for the sake of keeping with an idea that has been demonstrated to be flawed. If you are looking for fans of that idea, count me out ;-) Of course, if you are willing to put in the work to make it possible to restrict certain Git operations simply by using `chmod`, and to pay attention that it stays that way, go right ahead and submit a patch series to that end... Junio already indicated that he would not be flatly opposed to accept such changes ;-) Ciao, Johannes