From: Junio C Hamano <junkio@cox.net>
To: Andreas Ericsson <ae@op5.se>
Cc: git@vger.kernel.org
Subject: Re: User-relative paths
Date: Sun, 23 Oct 2005 12:56:11 -0700 [thread overview]
Message-ID: <7v1x2cyplw.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: 435B5AE0.1060400@op5.se
Andreas Ericsson <ae@op5.se> writes:
> Junio C Hamano wrote:
>> Andreas Ericsson <ae@op5.se> writes:
>> ...
>> At one point, Linus posted an outline of "restricted login shell
>> for use with git over ssh". I think you could start from there,
>> perhaps extend it so that it checks the binaries *and* pathnames
>> the user can specify (e.g. only under your own $HOME is allowed,
>> and no /../ in them, or something silly like that).
>>
>
> I found this in the archives:
> http://article.gmane.org/gmane.comp.version-control.git/5784/match=restricted+login
>
> Is that what you're referring to?
No, it is this one:
http://marc.theaimsgroup.com/?l=git&m=112681457828137&w=2
But it is orthogonal to what you are doing in this patch.
> Let me know if you want things done differently.
I think srvside_chdir() should not do the userdir expansion
under --strict (otherwise you would need a matching change in
daemon.c as well, but I would rather not).
The --strict flag in upload-pack is to make sure git-daemon can
see what is being accessed and make its policy decision even
before it calls upload-pack. In a pathological case, somebody
can create a directory "/~foo/bar/.git", where the "/~foo"
directory is different from "/home/foo", and have git-daemon
check that the former is OK and call your upload-pack. Your
upload-pack uses srvside_chdir() and exposes /home/foo/bar/.git;
this circumvents git-daemon's policy decision, doesn't it?
I also agree with everything Pasky already said.
* In a URL, a colon after hostname means "port number
follows". So it was a good intention to make these
consistent:
git fetch ssh://kernel.org:git
git fetch kernel.org:git
it should not be done. IOW, if I wanted to use the former
form (which I do not think I'd use myself), I should say either one
of:
git fetch ssh://kernel.org:~/git
git fetch ssh://kernel.org:~junio/git
Oh, I just noticed you do not handle the former, because you
did not have to, but now you need to.
* Use of "extern const char *__progname" is questionable. I
could be easily talked into:
- have "extern const char *git_program_name" in cache.h or
somewhere;
- convert programs (gradually) to set that at the beginning
of main();
- update die() and error() to use that variable when
reporting (both callers and implementation) -- this is
optional.
next prev parent reply other threads:[~2005-10-23 19:56 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-22 22:22 Server side programs Andreas Ericsson
2005-10-23 0:30 ` Junio C Hamano
2005-10-23 9:41 ` User-relative paths (was: Server side programs) Andreas Ericsson
2005-10-23 18:37 ` Petr Baudis
2005-10-23 19:50 ` User-relative paths Junio C Hamano
2005-10-23 22:25 ` Petr Baudis
2005-10-23 22:30 ` Junio C Hamano
2005-10-24 6:28 ` Daniel Barkalow
2005-10-25 7:47 ` Andreas Ericsson
2005-10-23 19:56 ` Junio C Hamano [this message]
2005-10-23 21:30 ` Linus Torvalds
2005-10-23 22:57 ` Junio C Hamano
2005-10-23 23:02 ` Junio C Hamano
2005-10-24 1:08 ` H. Peter Anvin
2005-10-24 1:37 ` Linus Torvalds
2005-10-24 1:44 ` H. Peter Anvin
2005-10-24 1:56 ` Junio C Hamano
2005-10-24 0:21 ` [PATCH] Add git-shell Junio C Hamano
2005-10-24 0:52 ` Linus Torvalds
2005-10-24 0:55 ` Linus Torvalds
2005-10-24 1:36 ` Junio C Hamano
2005-10-24 2:08 ` User-relative paths Junio C Hamano
2005-10-25 9:11 ` [PATCH] git_progname (was: Re: User-relative paths) Andreas Ericsson
2005-10-25 9:31 ` Petr Baudis
2005-10-25 11:12 ` [PATCH] git_progname Andreas Ericsson
2005-10-25 12:53 ` Andreas Ericsson
2005-10-25 13:32 ` Petr Baudis
2005-10-26 6:07 ` Junio C Hamano
2005-10-27 8:34 ` [PATCH] git_progname (was: Re: User-relative paths) Matthias Urlichs
2005-10-23 0:42 ` Server side programs Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7v1x2cyplw.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=ae@op5.se \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).