"Publishing your work" questions?

"Publishing your work" questions?

[Alan Chandler]

I am planning my way through switching over to using git (as opposed to 
subversion - via svnserve) to publish some stuff.

At the moment I leave a hole in my firewall for port 3690 and svnserve is run 
as a daemon from inetd.  I use svnserve's own user/realm management to limit 
the repositories I make public.

If I switch over to git, I assume I run git-daemon from inetd.

BUT

a) Is this what the git://my.domain.com/path/to/repository url refers to 
(neither get-pull-script nor git-fetch-script man pages actually say what 
this form means) ?

b) I can't find any mention in the documentation of what the default port 
should be. What is it?

c) Is git-daemon multithreaded (ie do I use nowait in inetd.conf)?

d) Is it possible to ensure that external accesses can't access anywhere in my 
filesystem? 

e) If I put my public key in ~git/.ssh/authorized_keys on the server, I can 
act as user git on the server via ssh.  Does git push support this?  

f) If I can do e), then perhaps [need to read the docs a bit harder] I can set 
up my user git on the machine to use git-receive-pack as its login shell.  
Will this work? - the tutorial talks about needing .bashrc to set up the 
$PATH environment, but are there any other hidden gotchas?

-- 
Alan Chandler
http://www.chandlerfamily.org.uk

Re: "Publishing your work" questions?

[Linus Torvalds]

On Sat, 20 Aug 2005, Alan Chandler wrote:
> 
> If I switch over to git, I assume I run git-daemon from inetd.

Yes. Use the "--inetd" flag, and open port 9418 instead.

> a) Is this what the git://my.domain.com/path/to/repository url refers to 
> (neither get-pull-script nor git-fetch-script man pages actually say what 
> this form means) ?

Yes.

> b) I can't find any mention in the documentation of what the default port 
> should be. What is it?

The default one is 9418, although you can use "--port=xxx" to set it to
something else. Obviously, if you put it at some other port, you either
need to re-compile the client side with the new port number (it's
DEFAULT_GIT_PORT in cache.h) or need to use

	git://my.domain.com:<port>/path/to/repository

> c) Is git-daemon multithreaded (ie do I use nowait in inetd.conf)?

Yup, it's entirely safe to run tons of them concurrently.

You can also run the git deamon without inetd, and it will do it's own 
serving. That normally limits it to 25 connections at a time.

> d) Is it possible to ensure that external accesses can't access anywhere in my 
> filesystem? 

Yes. The first thing the git-deamon will do is to chdir to the argument 
(and add ".git" to the end if it can't find the exact path), and then look 
up a file called "git-daemon-export-ok". If that file does not exist, it 
will exit.

This means, btw, that it will _not_ export any random git directory by 
default, much less anything else. You literally have to mark your git 
directories for export explicitly by doing a "touch git-daemon-export-ok" 
in the .git directory.

See "daemon.c: upload()" for some of the details.

> e) If I put my public key in ~git/.ssh/authorized_keys on the server, I can 
> act as user git on the server via ssh.  Does git push support this?  

Yes. That's the normal way to do it. The anonymous "git://" protocol can 
only do reads (adn it is entirely anonymous). For pushes, you _have_ to 
use ssh, either through

	git push my.domain.com:/path/to/repository

or

	git push ssh://my.domain.com/path/to/repository

(and you can obviously shorthand the format by putting it into your 
.git/remotes/ files, so that you can do things like "git push public".)

> f) If I can do e), then perhaps [need to read the docs a bit harder] I can set 
> up my user git on the machine to use git-receive-pack as its login shell.  
> Will this work? - the tutorial talks about needing .bashrc to set up the 
> $PATH environment, but are there any other hidden gotchas?

There shouldn't be any other gotchas. But no, you can't _quite_ use 
git-receive-pack as the login shell. Why? Because if you have it as your 
login shell, it will get the wrong arguments: it will get:

	0: git-receive-pack
	1: -c
	2: git-receive-pack '/path/to/repository'

and you'd need to have some ultra-simple shell that took this, verified
the proper arguments, and turned it into an

	execvp(git-receive-pack, /path/to/repository, NULL);

But yes, you _should_ be able to do it with that ultra-simplistic login 
shell. Probably just a 5-liner main() function or something.

			Linus

Re: "Publishing your work" questions?

[Linus Torvalds]

On Sat, 20 Aug 2005, Linus Torvalds wrote:
> 
> But yes, you _should_ be able to do it with that ultra-simplistic login 
> shell. Probably just a 5-liner main() function or something.

This is entirely untested, and a lot more than five lines of code. Edit 
until it works.

		Linus

----
#include <unistd.h>
#include <string.h>
#include <stdlib.h>

static char *parse_argument(char *orig)
{
	int i;
	int len = strlen(orig);

	/* We only accept properly quoted arguments */
	if (len < 2 || orig[0] != '\'' || orig[len-1] != '\'')
		exit(2);
	orig[len-1] = 0;
	orig++;
	len -= 2;

	/*
	 * Go look for quoted single-ticks. They are always
	 * quoted as '\'', we don't accept anything else
	 */
	for (i = 0; len ; i++, len--) {
		char c = orig[i];
		if (c != '\'')
			continue;
		if (len < 4 || memcmp(orig+i, "'\\''", 4))
			exit(2);
		len -= 3;
		memmove(orig+1, orig+4, len+1);
	}
	return orig;
}

int main(int argc, char **argv)
{
	int i;
	char *cmd, *arg;

	if (argc < 2)
		exit(1);
	i = 2;
	cmd = argv[1];
	if (!strcmp(cmd, "-c"))
		cmd = argv[i++];

	/* We're not going to allow anything else */
	if (argc != i)
		exit(1);

	/*
	 * Right now we only accept "upload" commands, but
	 * we could have some maintenance commands too, to
	 * create new archives or delete old ones..
	 */
	if (strncmp(cmd, "git-upload-pack ", 16))
		exit(1);

	arg = parse_argument(cmd+16);
	execlp("git-upload-pack", "git-upload-pack", arg, NULL);
	exit(3);
}

Re: "Publishing your work" questions?

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> 	/*
> 	 * Go look for quoted single-ticks. They are always
> 	 * quoted as '\'', we don't accept anything else
> 	 */

Oh, I am extremely glad to see that somebody else understands
exactly why I do things in the "seemingly very unoptimized" way
in sq_quote() --- it allows easy parsing for non-shell users.