Re: Pushing a git repository to a new server
On Mon, Feb 11, 2013 at 11:27 AM, Jeff King p...@peff.net wrote: [...] We talked about this a long time ago. One problem is that it's inherently unportable, as the procedure to make a repo is potentially different on every server (and certainly that is the case between a regular user running stock git and something like GitHub or Google Code; I imagine even gitolite has some special procedures for creating repos, too). I was more interested in creating something for my self rather than making any changes to the mainstream git. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pushing a git repository to a new server
On Mon, Feb 11, 2013 at 7:45 AM, Konstantin Khomoutov kostix+...@007spb.ru wrote: [...] OK, here's the sketch. On the server, in the home directory of your git user, you create a wrapper around git-receive-pack, like this: # mkdir ~git/git-shell-commands # cat ~git/git-shell-commands/git-receive-new-repo #!/bin/sh set -e -u if [ $# -ne 1 ]; then echo 'Missing required argument: directory' 2 exit 1 fi mkdir $1 git init --quiet --bare $1 git-receive-pack $1 ^D # chmod +x $_ Then, on the client side, to push a new repo, you just do $ git push --receive-pack=git-receive-new-repo --all git@server:repo.git This will make `git push` to spawn not just `git receive-pack dir` as it usually does but your wrapper, which would first create and initialize a bare repository and then spawn `git receive-pack` on it which would then communicate with the client side and receive everything from it. You could then create a client-side wrapper script or a Git alias for such creative pushing, like this: $ git config --add --global alias.push-new-repo \ 'push --receive-pack=git-receive-new-repo --all' So the whole client call is now reduced to $ git push-new-repo git@server:repo.git Thanks, that's what I was going for. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell
On Mon, Feb 11, 2013 at 12:22 AM, Junio C Hamano gits...@pobox.com wrote: Hmph, if that is the case, wouldn't it be a better direction to give a better help for majority of the case where git-shell is used as the login shell to allow push and fetch but not for interactive access at all? The first step in that direction may be to give a better canned message, followed by a mechanism (perhaps a hook) that lets a message customized for the site's needs, no? Why should a site administrator create an otherwise empty directory for each and every user and add an executable in there that shows an error message, only to improve the default message because it is not friendly enough? Jonathan made the following comment on the thread I started that lead to this RFC: You can disable interactive logins by removing the ~/git-shell-commands/ directory. Unfortunately that doesn't let you customize the message. Perhaps it would make sense to teach shell.c to look for a [shell] greeting = 'Hi %(username)! You've successfully authenticated, but I do not provide interactive shell access.' setting in git's config file. How is this for an alternative? Have shell.c look for [shell] missing_commands_directory = Stuff is broke. setting. If the setting is missing, then it prints the default message (the current message). That way, there's a default setting, there can be a system-wide message, there can be a user specific message, and those messages can be set via `git-commit`. -- Ethan Reesor -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] shell: pay attention to exit status from 'help' command
I feel like the suggestion I posted in response to Junio C Hamano
gits...@pobox.com's complaint on the RFC for this patch provides a
more elegant solution to the problem of administrators wanting to
prevent interactive sessions for users with their login shell set to
git-prompt. The suggestion was as follows:
How is this for an alternative? Have shell.c look for a
[shell]
missing_commands_directory = Stuff is broke.
setting. If the setting is missing, then it prints the default message
(the current message). That way, there's a default setting, there can
be a system-wide message, there can be a user specific message, and
those messages can be set via `git-config`.
On Mon, Feb 11, 2013 at 12:58 AM, Jonathan Nieder jrnie...@gmail.com wrote:
If I disable git-shell's interactive mode by removing the
~/git-shell-commands directory, then attempts to use 'ssh' with the
git account interactively produce an error message intended for the
administrator:
$ ssh git@myserver
fatal: Interactive git shell is not enabled.
hint: ~/git-shell-commands should exist and have read and execute
access.
$
That is helpful for the new admin who is wondering What? Why isn't
the git-shell I just set up working?, but once the site setup is
finished, it is better to give the user a friendly hint that she is on
the right track, like GitHub does:
Hi username! You've successfully authenticated, but
GitHub does not provide shell access.
An appropriate greeting might even include more complex information,
like a list of repositories the user has access to. If the
git-shell-commands directory exists and contains a help script, we
already run it when the shell is run without any commands, giving the
server a chance to provide a custom message. Unfortunately, the
presence of the git-shell-commands directory means we also enter an
interactive mode, prompting and accepting commands (of which there may
be none) from the user, which many servers would not want. To solve
this, we abort the interactive shell on a non-zero exit code from the
help script. This lets the server say whatever it likes, and then
hang up.
Downside: this will prevent interactive git-shell logins in existing
setups where the help script exits with nonzero status by mistake.
Hopefully those are rare enough to not cause much trouble in practice.
Reported-by: Ethan Reesor firelizz...@gmail.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
Improved-by: Jeff King p...@peff.net
---
Documentation/git-shell.txt | 20
shell.c | 10 --
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-shell.txt b/Documentation/git-shell.txt
index 4fe93203..60051e63 100644
--- a/Documentation/git-shell.txt
+++ b/Documentation/git-shell.txt
@@ -59,6 +59,26 @@ users to list repositories they have access to, create,
delete, or
rename repositories, or change repository descriptions and
permissions.
+If the `help` command exists and exits with nonzero status, the
+interactive shell is aborted.
+
+EXAMPLE
+---
+
+To disable interactive logins, displaying a greeting instead:
++
+
+$ chsh -s /usr/bin/git-shell
+$ mkdir $HOME/git-shell-commands
+$ cat $HOME/git-shell-commands/help \EOF
+#!/bin/sh
+printf '%s\n' Hi $USER! You've successfully authenticated, but I do not
+printf '%s\n' provide interactive shell access.
+exit 128
+EOF
+$ chmod +x $HOME/git-shell-commands/help
+
+
SEE ALSO
ssh(1),
diff --git a/shell.c b/shell.c
index 84b237fe..3abc2b84 100644
--- a/shell.c
+++ b/shell.c
@@ -63,10 +63,16 @@ static void cd_to_homedir(void)
static void run_shell(void)
{
- int done = 0;
+ int done = 0, status;
static const char *help_argv[] = { HELP_COMMAND, NULL };
/* Print help if enabled */
- run_command_v_opt(help_argv, RUN_SILENT_EXEC_FAILURE);
+ status = run_command_v_opt(help_argv, RUN_SILENT_EXEC_FAILURE);
+ if (!status)
+ ; /* success */
+ else if (status == -1 errno == ENOENT)
+ ; /* help disabled */
+ else
+ exit(status);
do {
struct strbuf line = STRBUF_INIT;
--
1.8.1.3
--
Ethan Reesor (Gmail)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell
I noticed a typo I made. I meant `git-config` rather than `git-commit`. Sorry for my mistake. On Mon, Feb 11, 2013 at 12:57 AM, Ethan Reesor firelizz...@gmail.com wrote: On Mon, Feb 11, 2013 at 12:22 AM, Junio C Hamano gits...@pobox.com wrote: Hmph, if that is the case, wouldn't it be a better direction to give a better help for majority of the case where git-shell is used as the login shell to allow push and fetch but not for interactive access at all? The first step in that direction may be to give a better canned message, followed by a mechanism (perhaps a hook) that lets a message customized for the site's needs, no? Why should a site administrator create an otherwise empty directory for each and every user and add an executable in there that shows an error message, only to improve the default message because it is not friendly enough? Jonathan made the following comment on the thread I started that lead to this RFC: You can disable interactive logins by removing the ~/git-shell-commands/ directory. Unfortunately that doesn't let you customize the message. Perhaps it would make sense to teach shell.c to look for a [shell] greeting = 'Hi %(username)! You've successfully authenticated, but I do not provide interactive shell access.' setting in git's config file. How is this for an alternative? Have shell.c look for [shell] missing_commands_directory = Stuff is broke. setting. If the setting is missing, then it prints the default message (the current message). That way, there's a default setting, there can be a system-wide message, there can be a user specific message, and those messages can be set via `git-commit`. -- Ethan Reesor -- Ethan Reesor (Gmail) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell
Why not have both? That way there is a way to get a customizable response that avoids Junio's complaints and there is a way to do what you are trying to achieve. On Mon, Feb 11, 2013 at 1:09 AM, Jonathan Nieder jrnie...@gmail.com wrote: Ethan Reesor wrote: That way, there's a default setting, there can be a system-wide message, there can be a user specific message, and those messages can be set via `git-commit`. That won't let me imitate gitolite's behavior without a lot of config file churn: $ ssh git@localhost Hello, jrn. This is git@elie running git-shell 1.8.1.3. R Wpath/to/one/repo R path/to/another/repo $ -- Ethan Reesor (Gmail) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell
On Mon, Feb 11, 2013 at 2:12 AM, Jonathan Nieder jrnie...@gmail.com wrote: Isn't that a criticism of the git-shell-commands facility in general? If it is common to have a lot of users with distinct home directories but all with git-shell as their login shell, then the git-shell-commands should not go in their home directory to begin with, no? I know nothing of the security issues, but why not have a /etc/git-shell-commands? -- Ethan Reesor (Gmail) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell
On Mon, Feb 11, 2013 at 2:22 AM, Junio C Hamano gits...@pobox.com wrote: Ethan Reesor firelizz...@gmail.com writes: Again, would it not be more elegant and powerful to A) have the shell-disabled message/hook/etc specified by git-config on some level, be it /etc/gitconfig or ~/.gitconfig, and B) have Jonathan's patch whereby ~/git-shell-commands/help returning non-zero closes the connection? Isn't that what I have essentially been saying? That is what you've been saying. I reiterated because I like the idea of having it managed via git config. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pushing a git repository to a new server
On Mon, Feb 11, 2013 at 2:50 AM, Konstantin Khomoutov kostix+...@007spb.ru wrote: What's wrong with $ ssh myuser@remotehost 'mkdir /path/to/MyRepo.git; cd $_; git init --bare' $ git push --all git@remotehost:MyOtherRepo.git ? Nothing, I just wanted to make myself a command to do that for me. The reason I had to use my user is the git user's shell is git-prompt There's no such thing as git-prompt. The restricted login shell for SSH-only access typically used for such a virtual Git user is git-shell. Sorry, git-prompt is something I made for myself. I meant git-shell. It's not really clear what do you want to achieve. The reason the git-shell shell is *restricted* (read its manual page) is to shrink the surface of possible attacks in the case the shell account used for accessing Git repos over SSH is compromized (the key or password stolen, for instance). This is achieved by only allowing commands like git-upload-pack etc in the shell (no general file manipulation commands etc). So what creating git command that can talk to the server using git-prompt ... would really buy you? I want to create a git-command that 1) creates a bare version of the current repo, 2) and uploads it to the specified path on my server (using tar, but that's not the point). My problem is that I have no idea how things like git-push works via a user with git-shell. Can you only run certain git commands, like git-upload-pack? Because I tried running 'ssh git@server git status' and that failed. I think the way to go is to start using gitolite [1] or implement by hand a subset of what it does (a custom login shell which is allowed to do certain things in a special area of the filesystem designated to keep Git repositories) or just set up a special account on the server (git-admin, for instance) which would have a regular login shell set for it and would be in the same group as the user git (or even have the same UID) so that they could share the files they create (subject to active umasks of processes run as both users though). I thought about the secondary user idea. I decided that trying to make my own command would be more fun. -- Ethan Reesor (Gmail) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
