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
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
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);
}