git/daemon.c, branch v1.2.2

daemon: extend user-relative path notation.

2006-02-06T00:51:01Z

Earlier, we made --base-path to automatically forbid user-relative paths, which was probably a mistake. This introduces --user-path (or --user-path=path) option to control the use of user-relative paths independently. The latter form of the option can be used to restrict accesses to a part of each user's home directory, similar to "public_html" some webservers supports. If we're invoked with --user-path=FOO option, then a URL of the form git://~USER/PATH/... resolves to the path HOME/FOO/PATH/..., where HOME is USER's home directory. [jc: This is much reworked by me so bugs are mine, but the original patch was done by Mark Wooding.] Signed-off-by: Junio C Hamano

daemon: Set SO_REUSEADDR on listening sockets.

2006-02-06T00:51:01Z

Without this, you can silently lose the ability to receive IPv4 connections if you stop and restart the daemon. [jc: tweaked code organization a bit and made this controllable from a command line option.] Signed-off-by: Mark Wooding Signed-off-by: Junio C Hamano

daemon: do not forbid user relative paths unconditionally under --base-path

2006-02-06T00:51:01Z

Using base-path to relocate the server public space does not have anything to do with allowing or forbidding user relative paths. Signed-off-by: Junio C Hamano

daemon: Provide missing argument for logerror() call.

2006-02-04T07:33:20Z

Could cause a crash if --base-path set. Unlikely to be a security the concern: message doesn't go to the client, so we can't leak anything (except by dumping core), and we've already forked, so it's not a denial of service. Signed-off-by: Mark Wooding Signed-off-by: Junio C Hamano

Exec git programs without using PATH.

2006-01-14T00:49:01Z

The git suite may not be in PATH (and thus programs such as git-send-pack could not exec git-rev-list). Thus there is a need for logic that will locate these programs. Modifying PATH is not desirable as it result in behavior differing from the user's intentions, as we may end up prepending "/usr/bin" to PATH. - git C programs will use exec*_git_cmd() APIs to exec sub-commands. - exec*_git_cmd() will execute a git program by searching for it in the following directories: 1. --exec-path (as used by "git") 2. The GIT_EXEC_PATH environment variable. 3. $(gitexecdir) as set in Makefile (default value $(bindir)). - git wrapper will modify PATH as before to enable shell scripts to invoke "git-foo" commands. Ideally, shell scripts should use the git wrapper to become independent of PATH, and then modifying PATH will not be necessary. [jc: with minor updates after a brief review.] Signed-off-by: Michal Ostrowski Signed-off-by: Junio C Hamano

git-daemon --base-path

2006-01-08T05:43:02Z

Tommi Virtanen expressed a wish on #git to be able to use short and elegant git URLs by making git-daemon 'root' in a given directory. This patch implements this, causing git-daemon to interpret all paths relative to the given base path if any is given. Signed-off-by: Petr Baudis Signed-off-by: Junio C Hamano

[PATCH] daemon.c and path.enter_repo(): revamp path validation.

2005-12-04T07:17:42Z

The whitelist of git-daemon is checked against return value from enter_repo(), and enter_repo() used to return the value obtained from getcwd() to avoid directory aliasing issues as discussed earier (mid October 2005). Unfortunately, it did not go well as we hoped. For example, /pub on a kernel.org public machine is a symlink to its real mountpoint, and it is understandable that the administrator does not want to adjust the whitelist every time /pub needs to point at a different partition for storage allcation or whatever reasons. Being able to keep using /pub/scm as the whitelist is a desirable property. So this version of enter_repo() reports what it used to chdir() and validate, but does not use getcwd() to canonicalize the directory name. When it sees a user relative path ~user/path, it internally resolves it to try chdir() there, but it still reports ~user/path (possibly after appending .git if allowed to do so, in which case it would report ~user/path.git). What this means is that if a whitelist wants to allow a user relative path, it needs to say "~" (for all users) or list user home directories like "~alice" "~bob". And no, you cannot say /home if the advertised way to access user home directories are ~alice,~bob, etc. The whole point of this is to avoid unnecessary aliasing issues. Anyway, because of this, daemon needs to do a bit more work to guard itself. Namely, it needs to make sure that the accessor does not try to exploit its leading path match rule by inserting /../ in the middle or hanging /.. at the end. I resurrected the belts and suspender paranoia code HPA did for this purpose. This check cannot be done in the enter_repo() unconditionally, because there are valid callers of enter_repo() that want to honor /../; authorized users coming over ssh to run send-pack and fetch-pack should be allowed to do so. Signed-off-by: Junio C Hamano

git-daemon not listening when compiled with -DNO_IPV6

2005-11-21T22:36:43Z

git-daemon was not listening when compiled with -DNO_IPV6. socksetup() was not returning socket count when compiled with -DNO_IPV6. Signed-off-by: Paul Serice Signed-off-by: Junio C Hamano

daemon: further tweaks.

2005-11-21T21:47:00Z

- Do validation only on canonicalized paths - Run upload-pack with "." as repository argument Signed-off-by: Junio C Hamano

git-daemon support for user-relative paths.

2005-11-21T21:47:00Z

Dropped a fair amount of reundant code in favour of the library code in path.c Added option --strict-paths with documentation, with backwards compatibility for whitelist entries with symlinks. Everything that worked earlier still works insofar as I have remembered testing it. Signed-off-by: Andreas Ericsson Signed-off-by: Junio C Hamano