From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.5 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id 5E38120988 for ; Tue, 18 Oct 2016 18:05:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965343AbcJRSF0 (ORCPT ); Tue, 18 Oct 2016 14:05:26 -0400 Received: from nm15-vm0.bullet.mail.ne1.yahoo.com ([98.138.91.70]:55596 "EHLO nm15-vm0.bullet.mail.ne1.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965157AbcJRSFW (ORCPT ); Tue, 18 Oct 2016 14:05:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1476814004; bh=UPnfOmX8BIl9g0CYRIIzu2YVS48NkDKVy6yDcAsSdq0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From:Subject; b=DWhyXD6fR1SQMcWc5CcdqU0gXXVhKdp+GLU3GBaY4k5XxtBH6dv9z03+DjIEwOAuksEn7HKoQ8TeJtY8I7QvhilXvoHl93mLN5UAxIcQif4GE5IlxYmx4QkwiG0TJDbJ/uNuYPetei2plw/paH3wnU5Ed1oDpo9rD5QNMyGQHICYVWmh5sz93SssKC4l4inBqaq1x+PK8wsPqF4dBfLDI7ongi3vKUKq4RqteJlTgtzrCoLcTPFmzzTMSlmbAnSAEn57X1XZ1IsVdGK6AAGDvtTIp//Y28Vi7dp/+NpdNY+kgjlBa8wpK6/oxTeQzjQiPQBcO5KI5uqdG/QPukpSyQ== Received: from [98.138.100.115] by nm15.bullet.mail.ne1.yahoo.com with NNFMP; 18 Oct 2016 18:06:44 -0000 Received: from [98.138.226.57] by tm106.bullet.mail.ne1.yahoo.com with NNFMP; 18 Oct 2016 18:05:21 -0000 Received: from [127.0.0.1] by smtp208.mail.ne1.yahoo.com with NNFMP; 18 Oct 2016 18:05:20 -0000 X-Yahoo-Newman-Id: 526801.66003.bm@smtp208.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: IooXZo8VM1nfpzRXB12mbwD0IBoSOakdFVcntKCTP0WWZFp 4FtBZF_coThttryy1dNGgunbMYEUT14lxj3gZlbZVCh20cO6URWktp.ekL5e fcEEFCCvsP8wVPGdjqZ2XYNyLfTVDe8QO7aEpI3yjFLCavWolTOqaPGyl_m5 oxD_J50cABCyrW5Jvt2nhhoE0CVEc_sqoTcndNbFB7dnEmIn6bJNCPGuEkXd tBN7xdrAbvzXRXzjh_76ivjuid4O9.YXuye3osf45_Xh06v.6wfcqo4Iah4k 0E5miNmHthbvegdhGE6kKEWV9IGf3.zN464SyzryC5F2WVWAyNsOnjmS9nqv kofzhXGUpN1JNU4WsukSWacDWl4Wi_oYommHJAU139rXDBmmwxHwZY8A_EsJ uvDkQPpBzhXS4TXjH2IKIfCHI0cHM1nC7G_vgSOkRG.i1ni4SufaAEX4DsHQ 7H9G599DY20A0sP9jV7LFIstv08imfNbJ9LHSNYcH5GC6DycJ5NJT.OgbMw5 t9Ck5lkHowIZSRY2mU7TxkyYwt.b7g5q0wI7dm2RAC_Oj19kYuAzgJ4mdtcE XqSVG X-Yahoo-SMTP: RfMTpXSswBAvHXkAeeQNI5gHzxpnJ2DwpMu4ffnqKdtAFQ-- Date: Tue, 18 Oct 2016 14:05:03 -0400 Message-ID: <87pomxildc.wl-lukeshu@sbcglobal.net> From: Luke Shumaker To: Junio C Hamano Cc: Luke Shumaker , git@vger.kernel.org, pclouds@gmail.com, peff@peff.net Subject: Re: [PATCH] daemon, path.c: fix a bug with ~ in repo paths In-Reply-To: References: <20161018150629.23205-1-lukeshu@sbcglobal.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Tue, 18 Oct 2016 13:08:45 -0400, Junio C Hamano wrote: > > Luke Shumaker writes: > > > The superficial aspect of this change is that git-daemon now allows paths > > that start with a "~". Previously, if git-daemon was run with > > "--base-path=/srv/git", it was impossible to get it to serve > > "/srv/git/~foo/bar.git". > > I am not sure I understand what you are saying here. Do you mean > > I have a path on my server /srv/git/~foo/bar.git; the tilde does > not mean anything special--it is just a byte in a valid pathname. > > I want to allow my users to say > > git fetch git://my.server/~foo/bar.git > > and fetch from that repository, but "git daemon" lacks the way > to configure to allow it. Yes, that is what I am saying. > If that is the case, what happens instead? Due to the leading > "~foo/" getting noticed as an attempt to use the user-path expansion > it is not treated as just a literal character? What happens instead is if (*dir == '~') { if (!user_path) { logerror("'%s': User-path not allowed", dir); return NULL; } which to the user looks like git clone git://my.server/~foo/bar.git Cloning into 'bar'... fatal: remote error: access denied or repository not exported: ~foo/bar.git > I am not sure if it is even a bug. As you can easily lose that > tilde that appears in front of subdirectory of /srv/git/ or replace > it with something else (e.g. "u/"), this smells like "Don't do it if > it hurts" thing to me. I buy into "Don't do it if it hurts", but that doesn't mean it's not a bug on an uncommon edge-case. Note that it doesn't hurt with git-shell or cgit (I haven't checked with gitweb). Many programs (especially shell scripts) fail to deal with filenames containing a space. "Don't put spaces in filenames if it hurts". It's still a bug in the program. Similarly, `git gui` used to not be able to add a file in a directory starting with '~' (when one clicked the file named "~foo/bar", it said something along the lines of "/home/~foo/bar is outside repository"), and one had to use `git add '~foo/bar` directly. "Don't do it if it hurts"; it was still a bug. Aside: one (somewhat silly) non-user reason that I've seen for a directory to start with '~' is that it sorts after all other ASCII characters; it moves the directory to the end of any lists. -- Happy hacking, ~ Luke Shumaker