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: Wed, 23 Sep 2015 13:10:35 +0200 Organization: gmx Message-ID: <5f56381a3cf5a5ccf6a1e4e3ea48f516@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> 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 Wed Sep 23 13:10:50 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 1Zehwl-0002Bb-5B for gcvg-git-2@plane.gmane.org; Wed, 23 Sep 2015 13:10:47 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753467AbbIWLKm (ORCPT ); Wed, 23 Sep 2015 07:10:42 -0400 Received: from mout.gmx.net ([212.227.15.18]:56974 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752638AbbIWLKl (ORCPT ); Wed, 23 Sep 2015 07:10:41 -0400 Received: from dscho.org ([87.106.4.80]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lk8CY-1aFPXT3FMI-00c5Oi; Wed, 23 Sep 2015 13:10:37 +0200 In-Reply-To: <1442955525.29498.94.camel@transmode.se> X-Sender: johannes.schindelin@gmx.de User-Agent: Roundcube Webmail/1.1.2 X-Provags-ID: V03:K0:nqgKNkJYfpTLX/VPDKYJnLjuJBH1SDMi6k2xo964+sPygHx8ogA eJ3pLCV24FRLkbaC+gOzDZqserXYJf/ku+CB4n1ornk5u1ZK9I7L+a7lK5Uh47MoR6dvABg /yz3G+df/D1HpPu0rjK146OG1JHctTnAzrI3iyAQ9eP2KG5YkgFgAqgt0EpJe/AdsfJkyV9 rows2p0JoGtIpnJj0aCyg== X-UI-Out-Filterresults: notjunk:1;V01:K0:vJOeP/JCQP0=:4n5jHom6Bn+aidMNBsUl8q Tn9ztVaB8mAeeNEnDE2KUNXGkldJSf1J6/+Oeb/5qWRaVyAoeecK/Zym3CP/oxK5w50k3/HP+ 4heAYYjsas5KYD85YkeQW5InJGOE4O9Mkn/7h/jmYfX70R0fonEg40koLdnqlv+sZWYJMh7oQ N6ktSfT2wgQNIrYDcn9ZWQVk415rgKesm6hf9zGly9IUDNiLDHAKRLvvmc05c3tTnnnj47sjw 3pUw9GlZovoYk5vTOPxfQ97yF8ynmrx4pqcN3F25fMDi8+0FKhQ0MwEhfDpGM1Bd9CVN9ePHv t39wPfHrZgtdd0P118MJh9rAdcWrNL+GInx34qo1HpgDEWIpKE9vIs4YDW2InN48R7L4wf0LS dhQe5neggdwEz4gfh0uLjAirzEIYbf8TYUWpf12kqdLFNZySWHYwrx/mYMGsPRO3d866zoWbT GFeUxKeoTxMHwT78wga1foAN5c8+WMmwEvlaBMvKzhe9OcsAzktT0DEPk2a4FJw0+8WlsUj5o MJaTweY0rnjz2lsNTsW27TaAEZl6nim20g/rNmNt2VL1AMMy7jTQJxKMiPZKlJcRnCcItNiLs ukG69zjbwShKwX40NqvZ0/Qs3mnAA+7qHbe/hVHatbj3I1adn//MzQOgFVktsqOtXU0X0hux7 EwGhOvGEqxLEpj6FXx/kyjfXALu2ZMDzMx/AgBkCCzVIh01/Xel7oA+JrYjF+H/ej+4ZJ7hVg cA8ryiLDLc4VzUgDD0/7za9z3jbe8xkVLHIYrg== Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Hi Joakim, 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. The original idea was really that you either own your repository, or you do not. And that includes the repositories that can be accessed publicly: you own them or you don't. Now, I know that in particular in some corporate setups, there needs to be a permission system in place that disallows certain users from doing certain things (such as editing the config). The Git solution is to set up a server, usually with SSH, and allow users to push and fetch from the repositories, but nothing else (i.e. no shell access), then set up hooks to implement the permission system. This is much less error prone than partially locking down a repository on some network drive because the file system structure simply does not reflect the permission structure. That is where all your troubles come from. >> But this idea you have, to somehow introduce fine-grained levels of control, this idea would imply that all >> of a sudden Git is no longer free to write to its files as it likes. And as far as Git is concerned, >> everything inside .git/ *are* its files. > > This does not compute for me, files inside git are git's files, I only > think that not all users > to a repo should have the same (write) access. But then it is your duty to tell *Git* what it can and what it cannot do. Typically via those hooks I mentioned. > A .git/tmp/ would make housekeeping easier, you would know that every > file under .git > should be there and if you find something you don't recognize you would react. No, it would actually make it harder. I seem to recall that there was some problem with renaming a file unless it was already in the same directory as the destination. If all files were to be written to .git/tmp/ first... >> If you need to exert more control in a specific repository, you simply make it accessible only as a non-file-system remote >> (where only `git`, `git-receive-pack` and `git-upload-pack` are allowed to be executed) and define hooks >> that can accept or deny on a *much* finer level than file system permissions ever could, after all. > > Even if I did go through this hassle, I would prefer if temporary data > were put somewhere else > than .git/ as I think mixing config/persistent data with temporary > data in the same directory is something > that should be avoided. Sure, I understand what you ask for. It's just that Git worked in a different direction for 10 years now ;-) Ciao, Johannes