From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 20175 invoked from network); 16 Jul 2021 06:41:01 -0000 Received: from 1ess.inri.net (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 16 Jul 2021 06:41:01 -0000 Received: from MTA-05-3.privateemail.com ([68.65.122.15]) by 1ess; Fri Jul 16 01:49:42 -0400 2021 Received: from mta-05.privateemail.com (localhost [127.0.0.1]) by mta-05.privateemail.com (Postfix) with ESMTP id 64BC518000AD for <9front@9front.org>; Fri, 16 Jul 2021 01:49:27 -0400 (EDT) Received: from localhost (unknown [10.20.151.243]) by mta-05.privateemail.com (Postfix) with ESMTPA id E04F0180009F for <9front@9front.org>; Fri, 16 Jul 2021 01:49:26 -0400 (EDT) Date: Thu, 15 Jul 2021 22:49:18 -0700 From: Anthony Martin To: 9front@9front.org Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: ClamAV using ClamSMTP List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: RESTful anonymous framework software-aware map/reduce optimizer Subject: [9front] git/fetch problem in group writable repositories Reply-To: 9front@9front.org Precedence: bulk If you create a git repository in a directory that is group writable, running git/fetch will leave behind an empty .git/objects/pack/fetch.tmp file with mode 0644 in a number of scenarios: - if passed the -l flag - if the local repository is up to date - if there is a fatal error in fetchpack If another user in the same group subsequently tries to run git/fetch, it will fail since the temporary pack file was not removed and cannot be overwritten. The calls to create need to be at least 0660 for files and 0770 for directories. It may also make sense to create the temporary files with OEXCL instead of truncating them if they already exist or to use a name that's less likely to be reused as in serve.c:/^updatepack. Another thing to think about it is if we should grab a lock of some kind before operations that will modify a repository that is group writable. Or just have a policy of "don't do that". Thoughts? Anthony