{"thread":{"id":"32875","subject":"Git prompt","startedAt":"2013-02-10T21:05:32Z","lastAt":"2013-03-12T10:47:25Z","messageCount":59,"participants":["Ethan Reesor","Jonathan Nieder","Jeff King","Junio C Hamano","Sitaram Chamarty","Ramkumar Ramachandra"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"209151","messageId":"CAE_TNikk-9sYVRQRwRecNpp3otQ+oc=uV9SPu+7pAkCUNbcUoQ@mail.gmail.com","threadId":"32875","inReplyTo":null,"subject":"Git prompt","fromName":"Ethan Reesor","fromEmail":"firelizzard@gmail.com","sentAt":"2013-02-10T21:05:32Z","receivedAt":"2013-02-10T21:05:32Z","isPatch":false,"sender":{"key":"firelizzard@gmail.com","avatar":"https://gravatar.com/avatar/65a178b01509a9c779e386b21651ed62eae41049adb69ed4ac31ea4a4dbdcd98?d=mp&s=160"},"body":"I have a git user set up on my server. It's prompt is set to\ngit-prompt and it's git-shell-commands is empty. The server works as a\ngit remote using ssh and the git user. When I `ssh git@server` I get a\nprompt where I can do nothing. When you ssh to github.com, you recieve\nthis message: \"Hi username! You've successfully authenticated, but\nGitHub does not provide shell access.\"\n\nHow do I make the git user work like github where, upon attempting to\nget a prompt, the connection is closed?\n\n--\nEthan Reesor\n"},{"id":"209153","messageId":"20130210212538.GA11720@elie.Belkin","threadId":"32875","inReplyTo":"CAE_TNikk-9sYVRQRwRecNpp3otQ+oc=uV9SPu+7pAkCUNbcUoQ@mail.gmail.com","subject":"Re: Git prompt","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-02-10T21:25:38Z","receivedAt":"2013-02-10T21:25:38Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ethan Reesor wrote:\n\n> I have a git user set up on my server. It's prompt is set to\n> git-prompt and it's git-shell-commands is empty.\n[...]\n> How do I make the git user work like github where, upon attempting to\n> get a prompt, the connection is closed?\n\nI assume you mean that the user's login shell is git-shell.\n\nYou can disable interactive logins by removing the\n~/git-shell-commands/ directory. Unfortunately that doesn't let you\ncustomize the message. Perhaps it would make sense to teach shell.c\nto look for a\n\n\t[shell]\n\t\tgreeting = 'Hi %(username)! You've successfully authenticated, but I do not provide interactive shell access.'\n\nsetting in git's config file. What do you think?\n\nThanks,\nJonathan\n"},{"id":"209159","messageId":"CAE_TNin6oAt7DkXH-iUNFHoeXhoJnJ_rSvEy=w=QPTB8F0tsLw@mail.gmail.com","threadId":"32875","inReplyTo":"20130210212538.GA11720@elie.Belkin","subject":"Re: Git prompt","fromName":"Ethan Reesor","fromEmail":"firelizzard@gmail.com","sentAt":"2013-02-10T21:54:36Z","receivedAt":"2013-02-10T21:54:36Z","isPatch":false,"sender":{"key":"firelizzard@gmail.com","avatar":"https://gravatar.com/avatar/65a178b01509a9c779e386b21651ed62eae41049adb69ed4ac31ea4a4dbdcd98?d=mp&s=160"},"body":"That would be perfect. (And I did mean I set the login shell to\ngit-prompt. Additionally, the git user does not have permissions to\nrun any other shell.) However, when I remove the git-shell-commands\ndirectory I get (on the local end):\n\nfatal: Interactive git shell is not enabled.\nhint: ~/git-shell-commands should exist and have read and execute access.\n\nIf no one with more experience has the time to look into your\nsuggestion, I will try.\n\nThanks,\nEthan\n\nOn Sun, Feb 10, 2013 at 4:25 PM, Jonathan Nieder wrote:\n> Ethan Reesor wrote:\n>\n>> I have a git user set up on my server. It's prompt is set to\n>> git-prompt and it's git-shell-commands is empty.\n> [...]\n>> How do I make the git user work like github where, upon attempting to\n>> get a prompt, the connection is closed?\n>\n> I assume you mean that the user's login shell is git-shell.\n>\n> You can disable interactive logins by removing the\n> ~/git-shell-commands/ directory. Unfortunately that doesn't let you\n> customize the message. Perhaps it would make sense to teach shell.c\n> to look for a\n>\n> [shell]\n> greeting = 'Hi %(username)! You've successfully authenticated, but I do not provide interactive shell access.'\n>\n> setting in git's config file. What do you think?\n>\n> Thanks,\n> Jonathan\n\n\n\n--\nEthan Reesor (Gmail)\n"},{"id":"209178","messageId":"20130210224345.GA32318@sigill.intra.peff.net","threadId":"32875","inReplyTo":"20130210212538.GA11720@elie.Belkin","subject":"Re: Git prompt","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-02-10T22:43:45Z","receivedAt":"2013-02-10T22:43:45Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 10, 2013 at 01:25:38PM -0800, Jonathan Nieder wrote:\n\n> Ethan Reesor wrote:\n> \n> > I have a git user set up on my server. It's prompt is set to\n> > git-prompt and it's git-shell-commands is empty.\n> [...]\n> > How do I make the git user work like github where, upon attempting to\n> > get a prompt, the connection is closed?\n> \n> I assume you mean that the user's login shell is git-shell.\n> \n> You can disable interactive logins by removing the\n> ~/git-shell-commands/ directory. Unfortunately that doesn't let you\n> customize the message. Perhaps it would make sense to teach shell.c\n> to look for a\n> \n> \t[shell]\n> \t\tgreeting = 'Hi %(username)! You've successfully authenticated, but I do not provide interactive shell access.'\n> \n> setting in git's config file. What do you think?\n\nI think something like that makes sense. To my knowledge there is no way\nwith stock git to customize git-shell's output (at GitHub, that message\ncomes from our front-end routing process before you even hit git-shell\non our backend machines).\n\nThe \"username\" in our version of the message comes from a database\nmapping public keys to GitHub users, not the Unix username. But I\nsuspect sites running stock Git would be happy enough to have\n%(username) map to the actual Unix username.\n\n-Peff\n"},{"id":"209183","messageId":"7vfw13rd9x.fsf@alter.siamese.dyndns.org","threadId":"32875","inReplyTo":"20130210224345.GA32318@sigill.intra.peff.net","subject":"Re: Git prompt","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-10T22:54:02Z","receivedAt":"2013-02-10T22:54:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Sun, Feb 10, 2013 at 01:25:38PM -0800, Jonathan Nieder wrote:\n>\n>> Ethan Reesor wrote:\n>> \n>> > I have a git user set up on my server. It's prompt is set to\n>> > git-prompt and it's git-shell-commands is empty.\n>> [...]\n>> > How do I make the git user work like github where, upon attempting to\n>> > get a prompt, the connection is closed?\n>> \n>> I assume you mean that the user's login shell is git-shell.\n>> \n>> You can disable interactive logins by removing the\n>> ~/git-shell-commands/ directory. Unfortunately that doesn't let you\n>> customize the message. Perhaps it would make sense to teach shell.c\n>> to look for a\n>> \n>> \t[shell]\n>> \t\tgreeting = 'Hi %(username)! You've successfully authenticated, but I do not provide interactive shell access.'\n>> \n>> setting in git's config file. What do you think?\n>\n> I think something like that makes sense. To my knowledge there is no way\n> with stock git to customize git-shell's output (at GitHub, that message\n> comes from our front-end routing process before you even hit git-shell\n> on our backend machines).\n>\n> The \"username\" in our version of the message comes from a database\n> mapping public keys to GitHub users, not the Unix username. But I\n> suspect sites running stock Git would be happy enough to have\n> %(username) map to the actual Unix username.\n\nYeah, that greeting is cute---I like it ;-)\n"},{"id":"209191","messageId":"CAMK1S_jFUXiHM6teVwoxO9gv77B1KBQoSi-B32dwVKemXnDx9w@mail.gmail.com","threadId":"32875","inReplyTo":"7vfw13rd9x.fsf@alter.siamese.dyndns.org","subject":"Re: Git prompt","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2013-02-11T00:43:49Z","receivedAt":"2013-02-11T00:43:49Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On Mon, Feb 11, 2013 at 4:24 AM, Junio C Hamano wrote:\n> Jeff King writes:\n>\n>> On Sun, Feb 10, 2013 at 01:25:38PM -0800, Jonathan Nieder wrote:\n>>\n>>> Ethan Reesor wrote:\n>>>\n>>> > I have a git user set up on my server. It's prompt is set to\n>>> > git-prompt and it's git-shell-commands is empty.\n>>> [...]\n>>> > How do I make the git user work like github where, upon attempting to\n>>> > get a prompt, the connection is closed?\n>>>\n>>> I assume you mean that the user's login shell is git-shell.\n>>>\n>>> You can disable interactive logins by removing the\n>>> ~/git-shell-commands/ directory. Unfortunately that doesn't let you\n>>> customize the message. Perhaps it would make sense to teach shell.c\n>>> to look for a\n>>>\n>>> [shell]\n>>> greeting = 'Hi %(username)! You've successfully authenticated, but I do not provide interactive shell access.'\n>>>\n>>> setting in git's config file. What do you think?\n>>\n>> I think something like that makes sense. To my knowledge there is no way\n>> with stock git to customize git-shell's output (at GitHub, that message\n>> comes from our front-end routing process before you even hit git-shell\n>> on our backend machines).\n>>\n>> The \"username\" in our version of the message comes from a database\n>> mapping public keys to GitHub users, not the Unix username. But I\n>> suspect sites running stock Git would be happy enough to have\n>> %(username) map to the actual Unix username.\n>\n> Yeah, that greeting is cute---I like it ;-)\n\nIndeed! In gitolite, I borrowed that idea added to it by making it\nprint a list of repos you have access to, along with what permissions\n(R or RW) you have :-)\n\nI'm not suggesting git should do that, but instead of a fixed string,\na default command to be executed would be better. That command could\ndo anything the local site wanted to make it do, including something\neqvt to what I just said.\n\nThis of course now means that the ~/git-shell-commands should not be\nempty, since that is where this default command also will be present.\n"},{"id":"209192","messageId":"20130211012016.GA13243@elie.Belkin","threadId":"32875","inReplyTo":"CAMK1S_jFUXiHM6teVwoxO9gv77B1KBQoSi-B32dwVKemXnDx9w@mail.gmail.com","subject":"[RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-02-11T01:20:16Z","receivedAt":"2013-02-11T01:20:16Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"If I disable git-shell's interactive mode by removing the\n~/git-shell-commands directory, then attempts to use 'ssh' with the\ngit account interactively produce an error message intended for the\nadministrator:\n\n\t$ ssh git@myserver\n\tfatal: Interactive git shell is not enabled.\n\thint: ~/git-shell-commands should exist and have read and execute access.\n\t$\n\nIt is better to give the user a friendly hint that she is on the\nright track, like GitHub does:\n\n\tHi ! You've successfully authenticated, but\n\tGitHub does not provide shell access.\n\nAn appropriate greeting might even include more complex information,\nlike a list of repositories the user has access to. A\ngit-shell-commands directory with only a \"help\" script can get us most\nof the way there, but it unfortunately it produces a \"git>\" prompt\nwhere the user can do nothing but ask for more help or exit. So allow\nthe \"help\" script to abort the shell by exiting with nonzero status.\n\nDownside: this will prevent interactive git-shell logins in existing\nsetups where the \"help\" script exits with nonzero status by mistake.\nHopefully those are rare enough to not cause much trouble in practice.\n\nReported-by: Ethan Reesor \nSigned-off-by: Jonathan Nieder \n---\nSitaram Chamarty wrote:\n\n> Indeed! In gitolite, I borrowed that idea added to it by making it\n> print a list of repos you have access to, along with what permissions\n> (R or RW) you have :-)\n>\n> I'm not suggesting git should do that, but instead of a fixed string,\n> a default command to be executed would be better.\n\nGood call.\n\n[...]\n> This of course now means that the ~/git-shell-commands should not be\n> empty, since that is where this default command also will be present.\n\nHow about this?\n\nA patch on top could change the default \"git-shell-commands is not\npresent\" message if that seems worthwhile.\n\n Documentation/git-shell.txt | 26 ++++++++++++++++++++++++++\n shell.c | 10 ++++++++--\n 2 files changed, 34 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-shell.txt b/Documentation/git-shell.txt\nindex 9b925060..758083ff 100644\n--- a/Documentation/git-shell.txt\n+++ b/Documentation/git-shell.txt\n@@ -29,6 +29,32 @@ read and execute permissions to the directory in order to execute the\n programs in it. The programs are executed with a cwd of $HOME, and\n is parsed as a command-line string.\n \n+When run interactively (with no arguments), 'git-shell' will\n+automatically run `~/git-shell-commands/help` on startup, provided it\n+exists. If the 'help' command fails then the interactive shell is\n+aborted.\n+\n+EXAMPLE\n+-------\n+\n+To disable interactive logins, displaying a greeting instead:\n++\n+----------------\n+$ chsh -s /usr/bin/git-shell\n+$ mkdir $HOME/git-shell-commands\n+$ cat >$HOME/git-shell-commands/help <<\\EOF\n+#!/bin/sh\n+printf '%s\\n' \"Hi $USER! You've successfully authenticated, but I do not\"\n+printf '%s\\n' \"provide interactive shell access.\"\n+exit 128\n+EOF\n+$ chmod +x $HOME/git-shell-commands/help\n+----------------\n+\n+SEE ALSO\n+--------\n+contrib/git-shell-commands/README\n+\n GIT\n ---\n Part of the linkgit:git[1] suite\ndiff --git a/shell.c b/shell.c\nindex 84b237fe..3abc2b84 100644\n--- a/shell.c\n+++ b/shell.c\n@@ -63,10 +63,16 @@ static void cd_to_homedir(void)\n \n static void run_shell(void)\n {\n-\tint done = 0;\n+\tint done = 0, status;\n \tstatic const char *help_argv[] = { HELP_COMMAND, NULL };\n \t/* Print help if enabled */\n-\trun_command_v_opt(help_argv, RUN_SILENT_EXEC_FAILURE);\n+\tstatus = run_command_v_opt(help_argv, RUN_SILENT_EXEC_FAILURE);\n+\tif (!status)\n+\t\t; /* success */\n+\telse if (status == -1 && errno == ENOENT)\n+\t\t; /* help disabled */\n+\telse\n+\t\texit(status);\n \n \tdo {\n \t\tstruct strbuf line = STRBUF_INIT;\n-- \n1.8.1.3\n"},{"id":"209196","messageId":"7v7gmfqzt1.fsf@alter.siamese.dyndns.org","threadId":"32875","inReplyTo":"20130211012016.GA13243@elie.Belkin","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-11T03:44:58Z","receivedAt":"2013-02-11T03:44:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> How about this?\n>\n> A patch on top could change the default \"git-shell-commands is not\n> present\" message if that seems worthwhile.\n\nHmph.\n\nI wonder if rewording the message when git-shell-commmands directory\nis not there may be a better first step (which actually could be the\nlast step)?\n\nThat is, showing something like this,\n\n> +printf '%s\\n' \"Hi $USER! You've successfully authenticated, but I do not\"\n> +printf '%s\\n' \"provide interactive shell access.\"\n\nbut rephrased with a reference to \"git help shell\" for people\npreparing their own server when ~/git-shell-commands/ in good order?\n\nSomething like\n\ndiff --git a/shell.c b/shell.c\nindex 84b237f..71ff04f 100644\n--- a/shell.c\n+++ b/shell.c\n@@ -162,9 +162,11 @@ int main(int argc, char **argv)\n \t\t/* Allow the user to run an interactive shell */\n \t\tcd_to_homedir();\n \t\tif (access(COMMAND_DIR, R_OK | X_OK) == -1) {\n-\t\t\tdie(\"Interactive git shell is not enabled.\\n\"\n+\t\t\tdie(\"The user has been recognized as '%s' but \"\n+\t\t\t \"interactive git shell is not enabled.\\n\"\n \t\t\t \"hint: ~/\" COMMAND_DIR \" should exist \"\n-\t\t\t \"and have read and execute access.\");\n+\t\t\t \"and have read and execute access.\",\n+\t\t\t get_user_name());\n \t\t}\n \t\trun_shell();\n \t\texit(0);\n"},{"id":"209198","messageId":"20130211035908.GA4543@sigill.intra.peff.net","threadId":"32875","inReplyTo":"20130211012016.GA13243@elie.Belkin","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-02-11T03:59:08Z","receivedAt":"2013-02-11T03:59:08Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 10, 2013 at 05:20:16PM -0800, Jonathan Nieder wrote:\n\n> > This of course now means that the ~/git-shell-commands should not be\n> > empty, since that is where this default command also will be present.\n> \n> How about this?\n\nI like the general direction this is going, but:\n\n> +When run interactively (with no arguments), 'git-shell' will\n> +automatically run `~/git-shell-commands/help` on startup, provided it\n> +exists. If the 'help' command fails then the interactive shell is\n> +aborted.\n\nDoesn't that mean that people who currently do allow interactive access\nand have a ~/git-shell-commands/help (that returns zero) will get\nspammed by its as a motd each time they connect?\n\nTo be honest, I am not really clear on what interactive git-shell is\nused for. AFAIK, it does nothing unless you have set up custom commands,\nand I have never actually seen them in the wild. So maybe it is not a\nbig deal.\n\nIf I understand correctly, calling it \"check-interactive\", \"greeting\",\nor something instead of \"help\" would be sufficient, and then you\nwouldn't have to worry about backwards compatibility.\n\n> diff --git a/shell.c b/shell.c\n> index 84b237fe..3abc2b84 100644\n> --- a/shell.c\n> +++ b/shell.c\n> @@ -63,10 +63,16 @@ static void cd_to_homedir(void)\n> \n> static void run_shell(void)\n> {\n> -\tint done = 0;\n> +\tint done = 0, status;\n> \tstatic const char *help_argv[] = { HELP_COMMAND, NULL };\n> \t/* Print help if enabled */\n> -\trun_command_v_opt(help_argv, RUN_SILENT_EXEC_FAILURE);\n> +\tstatus = run_command_v_opt(help_argv, RUN_SILENT_EXEC_FAILURE);\n> +\tif (!status)\n> +\t\t; /* success */\n> +\telse if (status == -1 && errno == ENOENT)\n> +\t\t; /* help disabled */\n> +\telse\n> +\t\texit(status);\n\nThis kicks in only when there is no command given, right? So if I ran\n\"ssh example.com\", it would give me the help message rather than (or in\naddition) giving me interactive access.\n\nWhat about \"ssh example.com foo\"? Do we want to allow a custom message\nthere, too (it might be different there; e.g., an allowed list of\ncommands might make more sense)?\n\n-Peff\n"},{"id":"209199","messageId":"20130211041404.GA15329@elie.Belkin","threadId":"32875","inReplyTo":"20130211035908.GA4543@sigill.intra.peff.net","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-02-11T04:14:04Z","receivedAt":"2013-02-11T04:14:04Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jeff King wrote:\n> On Sun, Feb 10, 2013 at 05:20:16PM -0800, Jonathan Nieder wrote:\n\n>> +When run interactively (with no arguments), 'git-shell' will\n>> +automatically run `~/git-shell-commands/help` on startup, provided it\n>> +exists. If the 'help' command fails then the interactive shell is\n>> +aborted.\n>\n> Doesn't that mean that people who currently do allow interactive access\n> and have a ~/git-shell-commands/help (that returns zero) will get\n> spammed by its as a motd each time they connect?\n\nOnly interactive connections. That's the existing behavior.\n\n[...]\n> What about \"ssh example.com foo\"? Do we want to allow a custom message\n> there, too (it might be different there; e.g., an allowed list of\n> commands might make more sense)?\n\nI wouldn't mind, but it's definitely not my itch.\n\nHoping that clarifies,\nJonathan\n"},{"id":"209200","messageId":"20130211041706.GB15329@elie.Belkin","threadId":"32875","inReplyTo":"7v7gmfqzt1.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-02-11T04:17:06Z","receivedAt":"2013-02-11T04:17:06Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n> Jonathan Nieder writes:\n\n>> How about this?\n>>\n>> A patch on top could change the default \"git-shell-commands is not\n>> present\" message if that seems worthwhile.\n>\n> Hmph.\n>\n> I wonder if rewording the message when git-shell-commmands directory\n> is not there may be a better first step (which actually could be the\n> last step)?\n\nMaybe, but it's not a step that I'm interested in. I don't think it\nchanges the desirability of the patch I sent. They are independent.\n\n[...]\n> --- a/shell.c\n> +++ b/shell.c\n> @@ -162,9 +162,11 @@ int main(int argc, char **argv)\n> \t\t/* Allow the user to run an interactive shell */\n> \t\tcd_to_homedir();\n> \t\tif (access(COMMAND_DIR, R_OK | X_OK) == -1) {\n> -\t\t\tdie(\"Interactive git shell is not enabled.\\n\"\n> +\t\t\tdie(\"The user has been recognized as '%s' but \"\n> +\t\t\t \"interactive git shell is not enabled.\\n\"\n> \t\t\t \"hint: ~/\" COMMAND_DIR \" should exist \"\n> -\t\t\t \"and have read and execute access.\");\n> +\t\t\t \"and have read and execute access.\",\n> +\t\t\t get_user_name());\n\nPersonally I don't think the hint should be here at all (it should be\nobvious that git-shell(1) is the place to read about the login\nbehavior of an account with shell set to git-shell), but I don't mind\nas long as it's possible to override the message.\n\nThanks,\nJonathan\n"},{"id":"209201","messageId":"20130211041714.GA12281@sigill.intra.peff.net","threadId":"32875","inReplyTo":"20130211041404.GA15329@elie.Belkin","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-02-11T04:17:14Z","receivedAt":"2013-02-11T04:17:14Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 10, 2013 at 08:14:04PM -0800, Jonathan Nieder wrote:\n\n> Jeff King wrote:\n> > On Sun, Feb 10, 2013 at 05:20:16PM -0800, Jonathan Nieder wrote:\n> \n> >> +When run interactively (with no arguments), 'git-shell' will\n> >> +automatically run `~/git-shell-commands/help` on startup, provided it\n> >> +exists. If the 'help' command fails then the interactive shell is\n> >> +aborted.\n> >\n> > Doesn't that mean that people who currently do allow interactive access\n> > and have a ~/git-shell-commands/help (that returns zero) will get\n> > spammed by its as a motd each time they connect?\n> \n> Only interactive connections. That's the existing behavior.\n\nAh, sorry. I misread the patch. I see now that we already run help, and\nthis is just making the exit value significant. In that case, yeah, I\nthink it's fine.\n\n-Peff\n"},{"id":"209202","messageId":"20130211042609.GC15329@elie.Belkin","threadId":"32875","inReplyTo":"20130211041714.GA12281@sigill.intra.peff.net","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-02-11T04:26:09Z","receivedAt":"2013-02-11T04:26:09Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jeff King wrote:\n> On Sun, Feb 10, 2013 at 08:14:04PM -0800, Jonathan Nieder wrote:\n\n>> Only interactive connections. That's the existing behavior.\n>\n> Ah, sorry. I misread the patch. I see now that we already run help, and\n> this is just making the exit value significant. In that case, yeah, I\n> think it's fine.\n\nNo problem --- the description was unclear. Would retitling the patch\nto \"shell: pay attention to exit status from 'help' command\" work?\n"},{"id":"209203","messageId":"7vwqufpj50.fsf@alter.siamese.dyndns.org","threadId":"32875","inReplyTo":"20130211041706.GB15329@elie.Belkin","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-11T04:30:19Z","receivedAt":"2013-02-11T04:30:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Junio C Hamano wrote:\n>> Jonathan Nieder writes:\n>\n>>> How about this?\n>>>\n>>> A patch on top could change the default \"git-shell-commands is not\n>>> present\" message if that seems worthwhile.\n>>\n>> Hmph.\n>>\n>> I wonder if rewording the message when git-shell-commmands directory\n>> is not there may be a better first step (which actually could be the\n>> last step)?\n>\n> Maybe, but it's not a step that I'm interested in. I don't think it\n> changes the desirability of the patch I sent. They are independent.\n\nWhat I thought I read in the log message was that you wanted to give\na better message telling the users that the site does _not_ allow an\ninteractive shell access. I do not see how that is independent from\na message given from this codepath, where the side has forbidden\nshell access by not having ~/git-shell-commands directory in the\nfirst place. Are you shooting for customizability?\n"},{"id":"209204","messageId":"20130211043247.GD15329@elie.Belkin","threadId":"32875","inReplyTo":"7vwqufpj50.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-02-11T04:32:47Z","receivedAt":"2013-02-11T04:32:47Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n> Are you shooting for customizability?\n\nYes, and the ability to generate the message dynamically.\n"},{"id":"209205","messageId":"20130211043322.GA12735@sigill.intra.peff.net","threadId":"32875","inReplyTo":"20130211042609.GC15329@elie.Belkin","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-02-11T04:33:22Z","receivedAt":"2013-02-11T04:33:22Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 10, 2013 at 08:26:09PM -0800, Jonathan Nieder wrote:\n\n> Jeff King wrote:\n> > On Sun, Feb 10, 2013 at 08:14:04PM -0800, Jonathan Nieder wrote:\n> \n> >> Only interactive connections. That's the existing behavior.\n> >\n> > Ah, sorry. I misread the patch. I see now that we already run help, and\n> > this is just making the exit value significant. In that case, yeah, I\n> > think it's fine.\n> \n> No problem --- the description was unclear. Would retitling the patch\n> to \"shell: pay attention to exit status from 'help' command\" work?\n\nI think what threw me off was reading the documentation part of the\npatch, which adds a note that we run \"help\" on startup, and then\nelaborates on the exit value. I didn't realize that the first half was\ndocumenting what already happened.\n\nTweaking the third paragraph of the commit message to:\n\n An appropriate greeting might even include more complex information,\n like a list of repositories the user has access to. If the\n git-shell-commands directory exists and contains a \"help\" script, we\n already run it when the shell is run without any commands, giving the\n server a chance to provide a custom message. Unfortunately, the\n presence of the git-shell-commands directory means we also enter an\n interactive mode, prompting and accepting commands (of which there may\n be none) from the user, which many servers would not want. To solve\n this, we abort the interactive shell on a non-zero exit code from the\n \"help\" script. This lets the server say whatever it likes, and then\n hangup.\n\nmakes it more clear to me. But once you explained it, I realize that I\nalso could have just read the C code part of the patch more carefully. :)\n\nSo I'm fine with or without that change.\n\n-Peff\n"},{"id":"209206","messageId":"20130211043629.GB12735@sigill.intra.peff.net","threadId":"32875","inReplyTo":"20130211043247.GD15329@elie.Belkin","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-02-11T04:36:29Z","receivedAt":"2013-02-11T04:36:29Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 10, 2013 at 08:32:47PM -0800, Jonathan Nieder wrote:\n\n> Junio C Hamano wrote:\n> \n> > Are you shooting for customizability?\n> \n> Yes, and the ability to generate the message dynamically.\n\nAs far as the default goes, I think the current one is OK, provided\nthere is an option to customize it (e.g., like your patch). Right now it\nis just nonsensical to random users (\"What? What in the world is\n~/git-shell-commands?\"). But once it is customizable, the main consumer\nof the message is admins who say \"What? Why isn't the git-shell I just\nset up working?\". The current message helps them diagnose the problem,\nand when they are ready to accept connections from random users, they'll\nwant something customizable anyway.\n\n-Peff\n"},{"id":"209207","messageId":"20130211044511.GA12809@sigill.intra.peff.net","threadId":"32875","inReplyTo":"20130211012016.GA13243@elie.Belkin","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-02-11T04:45:11Z","receivedAt":"2013-02-11T04:45:11Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 10, 2013 at 05:20:16PM -0800, Jonathan Nieder wrote:\n\n> diff --git a/shell.c b/shell.c\n> index 84b237fe..3abc2b84 100644\n> --- a/shell.c\n> +++ b/shell.c\n> @@ -63,10 +63,16 @@ static void cd_to_homedir(void)\n> \n> static void run_shell(void)\n> {\n> -\tint done = 0;\n> +\tint done = 0, status;\n> \tstatic const char *help_argv[] = { HELP_COMMAND, NULL };\n> \t/* Print help if enabled */\n> -\trun_command_v_opt(help_argv, RUN_SILENT_EXEC_FAILURE);\n> +\tstatus = run_command_v_opt(help_argv, RUN_SILENT_EXEC_FAILURE);\n> +\tif (!status)\n> +\t\t; /* success */\n> +\telse if (status == -1 && errno == ENOENT)\n> +\t\t; /* help disabled */\n> +\telse\n> +\t\texit(status);\n\nOne final comment on this. I believe we convert an exit code of 127 from\nthe child into ENOENT. So something like:\n\n #!/bin/sh\n echo >&2 \"Sorry, no interactive shells allowed.\"\n exti 1\n\nwould actually go into the \"help disabled\" code path and accidentally\nrun an interactive shell. I wondered if this is something that might\nhappen accidentally (since the old semantics of \"help\" were that exit\ncode did not matter), and if there might be security implications to\nentering an interactive shell. But I think we are OK for two reasons:\n\n 1. An old script would not be trying to exit with failure and\n expecting to abort the interactive session; that is a new feature\n you are adding. So even if we accidentally exit 127 (because the\n old script relied on a missing command), it is not changing the\n semantics.\n\n 2. Even if we accidentally do enter the interactive prompt, it should\n not be a security issue. It is not like you can then run arbitrary\n commands; unless you have put something else into\n ~/git-shell-commands, the user can only run \"help\" over and over.\n\nMaybe obvious, but I wanted to note it as part of the review. I think we\nneed to be extra careful with thinking through git-shell security\nimplications, since it is a major potential attack surface for many git\nsetups.\n\n-Peff\n"},{"id":"209208","messageId":"7vpq07pgpy.fsf@alter.siamese.dyndns.org","threadId":"32875","inReplyTo":"20130211043247.GD15329@elie.Belkin","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-11T05:22:33Z","receivedAt":"2013-02-11T05:22:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Junio C Hamano wrote:\n>\n>> Are you shooting for customizability?\n>\n> Yes, and the ability to generate the message dynamically.\n\nHmph, if that is the case, wouldn't it be a better direction to give\na better help for majority of the case where git-shell is used as\nthe login shell to allow push and fetch but not for interactive\naccess at all?\n\nThe first step in that direction may be to give a better canned\nmessage, followed by a mechanism (perhaps a hook) that lets a\nmessage customized for the site's needs, no? Why should a site\nadministrator create an otherwise empty directory for each and every\nuser and add an executable in there that shows an error message,\nonly to improve the default message because it is not friendly\nenough?\n\nI may be being slower than usual, but I am still not convinced...\n"},{"id":"209209","messageId":"20130211055604.GE15329@elie.Belkin","threadId":"32875","inReplyTo":"20130211043322.GA12735@sigill.intra.peff.net","subject":"[PATCH 0/2 v2] shell: allow 'help' command to disable interactive shell","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-02-11T05:56:04Z","receivedAt":"2013-02-11T05:56:04Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jeff King wrote:\n\n> I think what threw me off was reading the documentation part of the\n> patch, which adds a note that we run \"help\" on startup, and then\n> elaborates on the exit value. I didn't realize that the first half was\n> documenting what already happened.\n>\n> Tweaking the third paragraph of the commit message to:\n\nVery nice. How about this version?\n\nJonathan Nieder (2):\n shell doc: emphasize purpose and security guarantees\n shell: pay attention to exit status from 'help' command\n\n Documentation/git-shell.txt | 86 +++++++++++++++++++++++++++++++++++++--------\n shell.c | 10 ++++--\n 2 files changed, 79 insertions(+), 17 deletions(-)\n"},{"id":"209210","messageId":"CAE_TNim2wrL3SWxy_2ugyGmEFDngBJ8+z04y2tJFzMo4N8mUug@mail.gmail.com","threadId":"32875","inReplyTo":"7vpq07pgpy.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Ethan Reesor","fromEmail":"firelizzard@gmail.com","sentAt":"2013-02-11T05:57:28Z","receivedAt":"2013-02-11T05:57:28Z","isPatch":true,"sender":{"key":"firelizzard@gmail.com","avatar":"https://gravatar.com/avatar/65a178b01509a9c779e386b21651ed62eae41049adb69ed4ac31ea4a4dbdcd98?d=mp&s=160"},"body":"On Mon, Feb 11, 2013 at 12:22 AM, Junio C Hamano wrote:\n> Hmph, if that is the case, wouldn't it be a better direction to give\n> a better help for majority of the case where git-shell is used as\n> the login shell to allow push and fetch but not for interactive\n> access at all?\n>\n> The first step in that direction may be to give a better canned\n> message, followed by a mechanism (perhaps a hook) that lets a\n> message customized for the site's needs, no? Why should a site\n> administrator create an otherwise empty directory for each and every\n> user and add an executable in there that shows an error message,\n> only to improve the default message because it is not friendly\n> enough?\n\nJonathan made the following comment on the thread I started that lead\nto this RFC:\n> You can disable interactive logins by removing the\n> ~/git-shell-commands/ directory. Unfortunately that doesn't let you\n> customize the message. Perhaps it would make sense to teach shell.c\n> to look for a\n>\n> [shell]\n> greeting = 'Hi %(username)! You've successfully authenticated, but I do not provide interactive shell access.'\n>\n> setting in git's config file.\n\nHow is this for an alternative? Have shell.c look for\n [shell]\n missing_commands_directory = \"Stuff is broke.\"\nsetting. If the setting is missing, then it prints the default message\n(the current message). That way, there's a default setting, there can\nbe a system-wide message, there can be a user specific message, and\nthose messages can be set via `git-commit`.\n\n--\nEthan Reesor\n"},{"id":"209211","messageId":"20130211055752.GF15329@elie.Belkin","threadId":"32875","inReplyTo":"20130211055604.GE15329@elie.Belkin","subject":"[PATCH 1/2] shell doc: emphasize purpose and security model","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-02-11T05:57:52Z","receivedAt":"2013-02-11T05:57:52Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"The original git-shell(1) manpage emphasized that the shell\nsupports only git transport commands, and as the shell gained\nfeatures that emphasis and focus in the manual has been lost.\nBring it back by splitting the manpage into a few short sections\nand fleshing out each:\n\n - SYNOPSIS, describing how the shell gets used in practice\n - DESCRIPTION, which gives an overview of the purpose and\n guarantees provided by this restricted shell\n - COMMANDS, listing supported commands and restrictions on the\n arguments they accept\n - INTERACTIVE USE, describing the interactive mode\n\nAlso add a \"see also\" section with some relevant related reading.\n\nSigned-off-by: Jonathan Nieder \n---\nNew text. Split off from patch 2 --- this is just documenting\nexisting behavior.\n\n Documentation/git-shell.txt | 66 ++++++++++++++++++++++++++++++++++-----------\n 1 file changed, 51 insertions(+), 15 deletions(-)\n\ndiff --git a/Documentation/git-shell.txt b/Documentation/git-shell.txt\nindex 9b925060..4fe93203 100644\n--- a/Documentation/git-shell.txt\n+++ b/Documentation/git-shell.txt\n@@ -9,25 +9,61 @@ git-shell - Restricted login shell for Git-only SSH access\n SYNOPSIS\n --------\n [verse]\n-'git shell' [-c ]\n+'chsh' -s $(which git-shell) git\n+'git clone' `git@localhost:/path/to/repo.git`\n+'ssh' `git@localhost`\n \n DESCRIPTION\n -----------\n \n-A login shell for SSH accounts to provide restricted Git access. When\n-'-c' is given, the program executes non-interactively;\n- can be one of 'git receive-pack', 'git upload-pack', 'git\n-upload-archive', 'cvs server', or a command in COMMAND_DIR. The shell\n-is started in interactive mode when no arguments are given; in this\n-case, COMMAND_DIR must exist, and any of the executables in it can be\n-invoked.\n-\n-'cvs server' is a special command which executes git-cvsserver.\n-\n-COMMAND_DIR is the path \"$HOME/git-shell-commands\". The user must have\n-read and execute permissions to the directory in order to execute the\n-programs in it. The programs are executed with a cwd of $HOME, and\n- is parsed as a command-line string.\n+This is a login shell for SSH accounts to provide restricted Git access.\n+It permits execution only of server-side Git commands implementing the\n+pull/push functionality, plus custom commands present in a subdirectory\n+named `git-shell-commands` in the user's home directory.\n+\n+COMMANDS\n+--------\n+\n+'git shell' accepts the following commands after the '-c' option:\n+\n+'git receive-pack '::\n+'git upload-pack '::\n+'git upload-archive '::\n+\tCall the corresponding server-side command to support\n+\tthe client's 'git push', 'git fetch', or 'git archive --remote'\n+\trequest.\n+'cvs server'::\n+\tImitate a CVS server. See linkgit:git-cvsserver[1].\n+\n+If a `~/git-shell-commands` directory is present, 'git shell' will\n+also handle other, custom commands by running\n+\"`git-shell-commands/ `\" from the user's home\n+directory.\n+\n+INTERACTIVE USE\n+---------------\n+\n+By default, the commands above can be executed only with the '-c'\n+option; the shell is not interactive.\n+\n+If a `~/git-shell-commands` directory is present, 'git shell'\n+can also be run interactively (with no arguments). If a `help`\n+command is present in the `git-shell-commands` directory, it is\n+run to provide the user with an overview of allowed actions. Then a\n+\"`git> `\" prompt is presented at which one can enter any of the\n+commands from the `git-shell-commands` directory, or `exit` to close\n+the connection.\n+\n+Generally this mode is used as an administrative interface to allow\n+users to list repositories they have access to, create, delete, or\n+rename repositories, or change repository descriptions and\n+permissions.\n+\n+SEE ALSO\n+--------\n+ssh(1),\n+linkgit:git-daemon[1],\n+contrib/git-shell-commands/README\n \n GIT\n ---\n-- \n1.8.1.3\n"},{"id":"209212","messageId":"20130211055847.GG15329@elie.Belkin","threadId":"32875","inReplyTo":"20130211055604.GE15329@elie.Belkin","subject":"[PATCH 2/2] shell: pay attention to exit status from 'help' command","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-02-11T05:58:47Z","receivedAt":"2013-02-11T05:58:47Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"If I disable git-shell's interactive mode by removing the\n~/git-shell-commands directory, then attempts to use 'ssh' with the\ngit account interactively produce an error message intended for the\nadministrator:\n\n\t$ ssh git@myserver\n\tfatal: Interactive git shell is not enabled.\n\thint: ~/git-shell-commands should exist and have read and execute access.\n\t$\n\nThat is helpful for the new admin who is wondering \"What? Why isn't\nthe git-shell I just set up working?\", but once the site setup is\nfinished, it is better to give the user a friendly hint that she is on\nthe right track, like GitHub does:\n\n\tHi ! You've successfully authenticated, but\n\tGitHub does not provide shell access.\n\nAn appropriate greeting might even include more complex information,\nlike a list of repositories the user has access to. If the\ngit-shell-commands directory exists and contains a \"help\" script, we\nalready run it when the shell is run without any commands, giving the\nserver a chance to provide a custom message. Unfortunately, the\npresence of the git-shell-commands directory means we also enter an\ninteractive mode, prompting and accepting commands (of which there may\nbe none) from the user, which many servers would not want. To solve\nthis, we abort the interactive shell on a non-zero exit code from the\n\"help\" script. This lets the server say whatever it likes, and then\nhang up.\n\nDownside: this will prevent interactive git-shell logins in existing\nsetups where the \"help\" script exits with nonzero status by mistake.\nHopefully those are rare enough to not cause much trouble in practice.\n\nReported-by: Ethan Reesor \nSigned-off-by: Jonathan Nieder \nImproved-by: Jeff King \n---\n Documentation/git-shell.txt | 20 ++++++++++++++++++++\n shell.c | 10 ++++++++--\n 2 files changed, 28 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-shell.txt b/Documentation/git-shell.txt\nindex 4fe93203..60051e63 100644\n--- a/Documentation/git-shell.txt\n+++ b/Documentation/git-shell.txt\n@@ -59,6 +59,26 @@ users to list repositories they have access to, create, delete, or\n rename repositories, or change repository descriptions and\n permissions.\n \n+If the `help` command exists and exits with nonzero status, the\n+interactive shell is aborted.\n+\n+EXAMPLE\n+-------\n+\n+To disable interactive logins, displaying a greeting instead:\n++\n+----------------\n+$ chsh -s /usr/bin/git-shell\n+$ mkdir $HOME/git-shell-commands\n+$ cat >$HOME/git-shell-commands/help <<\\EOF\n+#!/bin/sh\n+printf '%s\\n' \"Hi $USER! You've successfully authenticated, but I do not\"\n+printf '%s\\n' \"provide interactive shell access.\"\n+exit 128\n+EOF\n+$ chmod +x $HOME/git-shell-commands/help\n+----------------\n+\n SEE ALSO\n --------\n ssh(1),\ndiff --git a/shell.c b/shell.c\nindex 84b237fe..3abc2b84 100644\n--- a/shell.c\n+++ b/shell.c\n@@ -63,10 +63,16 @@ static void cd_to_homedir(void)\n \n static void run_shell(void)\n {\n-\tint done = 0;\n+\tint done = 0, status;\n \tstatic const char *help_argv[] = { HELP_COMMAND, NULL };\n \t/* Print help if enabled */\n-\trun_command_v_opt(help_argv, RUN_SILENT_EXEC_FAILURE);\n+\tstatus = run_command_v_opt(help_argv, RUN_SILENT_EXEC_FAILURE);\n+\tif (!status)\n+\t\t; /* success */\n+\telse if (status == -1 && errno == ENOENT)\n+\t\t; /* help disabled */\n+\telse\n+\t\texit(status);\n \n \tdo {\n \t\tstruct strbuf line = STRBUF_INIT;\n-- \n1.8.1.3\n"},{"id":"209213","messageId":"CAE_TNikNH_8eUyX7s_zkY5FWEgyYXM617DG+j+3f1jOFC1Ud1w@mail.gmail.com","threadId":"32875","inReplyTo":"20130211055847.GG15329@elie.Belkin","subject":"Re: [PATCH 2/2] shell: pay attention to exit status from 'help' command","fromName":"Ethan Reesor","fromEmail":"firelizzard@gmail.com","sentAt":"2013-02-11T06:06:17Z","receivedAt":"2013-02-11T06:06:17Z","isPatch":true,"sender":{"key":"firelizzard@gmail.com","avatar":"https://gravatar.com/avatar/65a178b01509a9c779e386b21651ed62eae41049adb69ed4ac31ea4a4dbdcd98?d=mp&s=160"},"body":"I feel like the suggestion I posted in response to Junio C Hamano\n's complaint on the RFC for this patch provides a\nmore elegant solution to the problem of administrators wanting to\nprevent interactive sessions for users with their login shell set to\ngit-prompt. The suggestion was as follows:\n\n> How is this for an alternative? Have shell.c look for a\n> [shell]\n> missing_commands_directory = \"Stuff is broke.\"\n> setting. If the setting is missing, then it prints the default message\n> (the current message). That way, there's a default setting, there can\n> be a system-wide message, there can be a user specific message, and\n> those messages can be set via `git-config`.\n\nOn Mon, Feb 11, 2013 at 12:58 AM, Jonathan Nieder wrote:\n> If I disable git-shell's interactive mode by removing the\n> ~/git-shell-commands directory, then attempts to use 'ssh' with the\n> git account interactively produce an error message intended for the\n> administrator:\n>\n> $ ssh git@myserver\n> fatal: Interactive git shell is not enabled.\n> hint: ~/git-shell-commands should exist and have read and execute access.\n> $\n>\n> That is helpful for the new admin who is wondering \"What? Why isn't\n> the git-shell I just set up working?\", but once the site setup is\n> finished, it is better to give the user a friendly hint that she is on\n> the right track, like GitHub does:\n>\n> Hi ! You've successfully authenticated, but\n> GitHub does not provide shell access.\n>\n> An appropriate greeting might even include more complex information,\n> like a list of repositories the user has access to. If the\n> git-shell-commands directory exists and contains a \"help\" script, we\n> already run it when the shell is run without any commands, giving the\n> server a chance to provide a custom message. Unfortunately, the\n> presence of the git-shell-commands directory means we also enter an\n> interactive mode, prompting and accepting commands (of which there may\n> be none) from the user, which many servers would not want. To solve\n> this, we abort the interactive shell on a non-zero exit code from the\n> \"help\" script. This lets the server say whatever it likes, and then\n> hang up.\n>\n> Downside: this will prevent interactive git-shell logins in existing\n> setups where the \"help\" script exits with nonzero status by mistake.\n> Hopefully those are rare enough to not cause much trouble in practice.\n>\n> Reported-by: Ethan Reesor \n> Signed-off-by: Jonathan Nieder \n> Improved-by: Jeff King \n> ---\n> Documentation/git-shell.txt | 20 ++++++++++++++++++++\n> shell.c | 10 ++++++++--\n> 2 files changed, 28 insertions(+), 2 deletions(-)\n>\n> diff --git a/Documentation/git-shell.txt b/Documentation/git-shell.txt\n> index 4fe93203..60051e63 100644\n> --- a/Documentation/git-shell.txt\n> +++ b/Documentation/git-shell.txt\n> @@ -59,6 +59,26 @@ users to list repositories they have access to, create, delete, or\n> rename repositories, or change repository descriptions and\n> permissions.\n>\n> +If the `help` command exists and exits with nonzero status, the\n> +interactive shell is aborted.\n> +\n> +EXAMPLE\n> +-------\n> +\n> +To disable interactive logins, displaying a greeting instead:\n> ++\n> +----------------\n> +$ chsh -s /usr/bin/git-shell\n> +$ mkdir $HOME/git-shell-commands\n> +$ cat >$HOME/git-shell-commands/help <<\\EOF\n> +#!/bin/sh\n> +printf '%s\\n' \"Hi $USER! You've successfully authenticated, but I do not\"\n> +printf '%s\\n' \"provide interactive shell access.\"\n> +exit 128\n> +EOF\n> +$ chmod +x $HOME/git-shell-commands/help\n> +----------------\n> +\n> SEE ALSO\n> --------\n> ssh(1),\n> diff --git a/shell.c b/shell.c\n> index 84b237fe..3abc2b84 100644\n> --- a/shell.c\n> +++ b/shell.c\n> @@ -63,10 +63,16 @@ static void cd_to_homedir(void)\n>\n> static void run_shell(void)\n> {\n> - int done = 0;\n> + int done = 0, status;\n> static const char *help_argv[] = { HELP_COMMAND, NULL };\n> /* Print help if enabled */\n> - run_command_v_opt(help_argv, RUN_SILENT_EXEC_FAILURE);\n> + status = run_command_v_opt(help_argv, RUN_SILENT_EXEC_FAILURE);\n> + if (!status)\n> + ; /* success */\n> + else if (status == -1 && errno == ENOENT)\n> + ; /* help disabled */\n> + else\n> + exit(status);\n>\n> do {\n> struct strbuf line = STRBUF_INIT;\n> --\n> 1.8.1.3\n>\n\n\n\n--\nEthan Reesor (Gmail)\n"},{"id":"209214","messageId":"CAE_TNinMTtH3U-3T5AO5zV-L_RB82_R_i2ZNbNz7KE5L=JX-KA@mail.gmail.com","threadId":"32875","inReplyTo":"CAE_TNim2wrL3SWxy_2ugyGmEFDngBJ8+z04y2tJFzMo4N8mUug@mail.gmail.com","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Ethan Reesor","fromEmail":"firelizzard@gmail.com","sentAt":"2013-02-11T06:07:13Z","receivedAt":"2013-02-11T06:07:13Z","isPatch":true,"sender":{"key":"firelizzard@gmail.com","avatar":"https://gravatar.com/avatar/65a178b01509a9c779e386b21651ed62eae41049adb69ed4ac31ea4a4dbdcd98?d=mp&s=160"},"body":"I noticed a typo I made. I meant `git-config` rather than\n`git-commit`. Sorry for my mistake.\n\nOn Mon, Feb 11, 2013 at 12:57 AM, Ethan Reesor wrote:\n> On Mon, Feb 11, 2013 at 12:22 AM, Junio C Hamano wrote:\n>> Hmph, if that is the case, wouldn't it be a better direction to give\n>> a better help for majority of the case where git-shell is used as\n>> the login shell to allow push and fetch but not for interactive\n>> access at all?\n>>\n>> The first step in that direction may be to give a better canned\n>> message, followed by a mechanism (perhaps a hook) that lets a\n>> message customized for the site's needs, no? Why should a site\n>> administrator create an otherwise empty directory for each and every\n>> user and add an executable in there that shows an error message,\n>> only to improve the default message because it is not friendly\n>> enough?\n>\n> Jonathan made the following comment on the thread I started that lead\n> to this RFC:\n>> You can disable interactive logins by removing the\n>> ~/git-shell-commands/ directory. Unfortunately that doesn't let you\n>> customize the message. Perhaps it would make sense to teach shell.c\n>> to look for a\n>>\n>> [shell]\n>> greeting = 'Hi %(username)! You've successfully authenticated, but I do not provide interactive shell access.'\n>>\n>> setting in git's config file.\n>\n> How is this for an alternative? Have shell.c look for\n> [shell]\n> missing_commands_directory = \"Stuff is broke.\"\n> setting. If the setting is missing, then it prints the default message\n> (the current message). That way, there's a default setting, there can\n> be a system-wide message, there can be a user specific message, and\n> those messages can be set via `git-commit`.\n>\n> --\n> Ethan Reesor\n\n\n\n--\nEthan Reesor (Gmail)\n"},{"id":"209215","messageId":"20130211060911.GH15329@elie.Belkin","threadId":"32875","inReplyTo":"CAE_TNim2wrL3SWxy_2ugyGmEFDngBJ8+z04y2tJFzMo4N8mUug@mail.gmail.com","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-02-11T06:09:11Z","receivedAt":"2013-02-11T06:09:11Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ethan Reesor wrote:\n\n> That way, there's a default setting, there can\n> be a system-wide message, there can be a user specific message, and\n> those messages can be set via `git-commit`.\n\nThat won't let me imitate gitolite's behavior without a lot of\nconfig file churn:\n\n\t$ ssh git@localhost\n\tHello, jrn. This is git@elie running git-shell 1.8.1.3.\n\n\t R W\tpath/to/one/repo\n\t R\tpath/to/another/repo\n\t$\n"},{"id":"209216","messageId":"CAE_TNi=fN66+9WfMn86H6J_BVAjFP=xiE8m3JHe_4ANHB2V5wA@mail.gmail.com","threadId":"32875","inReplyTo":"20130211060911.GH15329@elie.Belkin","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Ethan Reesor","fromEmail":"firelizzard@gmail.com","sentAt":"2013-02-11T06:11:21Z","receivedAt":"2013-02-11T06:11:21Z","isPatch":true,"sender":{"key":"firelizzard@gmail.com","avatar":"https://gravatar.com/avatar/65a178b01509a9c779e386b21651ed62eae41049adb69ed4ac31ea4a4dbdcd98?d=mp&s=160"},"body":"Why not have both? That way there is a way to get a customizable\nresponse that avoids Junio's complaints and there is a way to do what\nyou are trying to achieve.\n\nOn Mon, Feb 11, 2013 at 1:09 AM, Jonathan Nieder wrote:\n> Ethan Reesor wrote:\n>\n>> That way, there's a default setting, there can\n>> be a system-wide message, there can be a user specific message, and\n>> those messages can be set via `git-commit`.\n>\n> That won't let me imitate gitolite's behavior without a lot of\n> config file churn:\n>\n> $ ssh git@localhost\n> Hello, jrn. This is git@elie running git-shell 1.8.1.3.\n>\n> R W path/to/one/repo\n> R path/to/another/repo\n> $\n\n\n\n--\nEthan Reesor (Gmail)\n"},{"id":"209217","messageId":"20130211061442.GI15329@elie.Belkin","threadId":"32875","inReplyTo":"7vpq07pgpy.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-02-11T06:14:43Z","receivedAt":"2013-02-11T06:14:43Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n> Jonathan Nieder writes:\n>> Junio C Hamano wrote:\n\n>>> Are you shooting for customizability?\n>>\n>> Yes, and the ability to generate the message dynamically.\n>\n> Hmph, if that is the case, wouldn't it be a better direction to give\n> a better help for majority of the case where git-shell is used as\n> the login shell to allow push and fetch but not for interactive\n> access at all?\n>\n> The first step in that direction may be to give a better canned\n> message, followed by a mechanism (perhaps a hook) that lets a\n> message customized for the site's needs, no?\n\nThe trouble is that I can't imagine a canned message that everyone\nwill like. (For example, I quite dislike the current one.) That's\nexactly the situation in which some configurability is helpful.\n\nSome configurability is nice for other situations, anyway. For\nexample, sites serving a multilingual audience may want the message to\nvary based on the user's language (or even source IP). The message\ncan include a list of available repositories or extra information that\nchanges over time. And so on.\n\nHope that helps,\nJonathan\n"},{"id":"209218","messageId":"20130211061553.GJ15329@elie.Belkin","threadId":"32875","inReplyTo":"CAE_TNi=fN66+9WfMn86H6J_BVAjFP=xiE8m3JHe_4ANHB2V5wA@mail.gmail.com","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-02-11T06:15:53Z","receivedAt":"2013-02-11T06:15:53Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"[administrivia: please don't top-post]\nEthan Reesor wrote:\n\n> Why not have both? That way there is a way to get a customizable\n> response that avoids Junio's complaints and there is a way to do what\n> you are trying to achieve.\n\nWhat was Junio's complaint?\n\nJonathan\n"},{"id":"209220","messageId":"CAE_TNimshLGK=Asv1nc=TrPJ89ZHMqOo0p32bRi5EGv2jZHdUw@mail.gmail.com","threadId":"32875","inReplyTo":"20130211061553.GJ15329@elie.Belkin","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Ethan Reesor","fromEmail":"firelizzard@gmail.com","sentAt":"2013-02-11T06:22:27Z","receivedAt":"2013-02-11T06:22:27Z","isPatch":true,"sender":{"key":"firelizzard@gmail.com","avatar":"https://gravatar.com/avatar/65a178b01509a9c779e386b21651ed62eae41049adb69ed4ac31ea4a4dbdcd98?d=mp&s=160"},"body":"On Mon, Feb 11, 2013 at 1:15 AM, Jonathan Nieder wrote:\n> [administrivia: please don't top-post]\n> Ethan Reesor wrote:\n>\n>> Why not have both? That way there is a way to get a customizable\n>> response that avoids Junio's complaints and there is a way to do what\n>> you are trying to achieve.\n>\n> What was Junio's complaint?\n\nI was referring to the one you recently addressed:\n\nOn Mon, Feb 11, 2013 at 1:14 AM, Jonathan Nieder wrote:\n> Junio C Hamano wrote:\n>> Jonathan Nieder writes:\n>>> Junio C Hamano wrote:\n>\n>>>> Are you shooting for customizability?\n>>>\n>>> Yes, and the ability to generate the message dynamically.\n>>\n>> Hmph, if that is the case, wouldn't it be a better direction to give\n>> a better help for majority of the case where git-shell is used as\n>> the login shell to allow push and fetch but not for interactive\n>> access at all?\n>>\n>> The first step in that direction may be to give a better canned\n>> message, followed by a mechanism (perhaps a hook) that lets a\n>> message customized for the site's needs, no?\n>\n> The trouble is that I can't imagine a canned message that everyone\n> will like. (For example, I quite dislike the current one.) That's\n> exactly the situation in which some configurability is helpful.\n>\n> Some configurability is nice for other situations, anyway. For\n> example, sites serving a multilingual audience may want the message to\n> vary based on the user's language (or even source IP). The message\n> can include a list of available repositories or extra information that\n> changes over time. And so on.\n>\n> Hope that helps,\n> Jonathan\n\nWhen I made my suggestion, I was tempted to say that both methods\n(having help return non-zero and allowing a git-configurable response)\nshould be included, but I couldn't think of a reason to include both\nuntil you brought your use case back up.\n\n--\nEthan Reesor (Gmail)\n"},{"id":"209221","messageId":"7vliavpc4q.fsf@alter.siamese.dyndns.org","threadId":"32875","inReplyTo":"20130211061442.GI15329@elie.Belkin","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-11T07:01:41Z","receivedAt":"2013-02-11T07:01:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Junio C Hamano wrote:\n>> Jonathan Nieder writes:\n>>> Junio C Hamano wrote:\n>\n>>>> Are you shooting for customizability?\n>>>\n>>> Yes, and the ability to generate the message dynamically.\n>>\n>> Hmph, if that is the case, wouldn't it be a better direction to give\n>> a better help for majority of the case where git-shell is used as\n>> the login shell to allow push and fetch but not for interactive\n>> access at all?\n>>\n>> The first step in that direction may be to give a better canned\n>> message, followed by a mechanism (perhaps a hook) that lets a\n>> message customized for the site's needs, no?\n>\n> The trouble is that I can't imagine a canned message that everyone\n> will like. (For example, I quite dislike the current one.) That's\n> exactly the situation in which some configurability is helpful.\n\nI am not saying we should have a perfect canned message everybody\nlikes and not have any configurability. I however think we can aim\nto come up with a message that covers 80% of site administrators who\ndo not care too much and just want git-shell to allow the standard\nservices without giving any custom command.\n\nAnd for the remaining 20% of those who do not like the canned\nmessage but still do not need any custom command, I think it is way\nsuboptimal to force them to create git-shell-commands directory for\n47 users his host gives git-shell access to, and copy the \"help\"\nscript to all of them, only to get a customized message. It would\nhelp them quite a lot if you just called /etc/git/shell-disabled or\nsome hook that generates a customized message; then there is no need\nto add any git-shell-commands directory and a \"help\" script every\ntime he gets one new user, no?\n\nFor those who _do_ want to give customized commands to their users,\nthey can already have \"help\" script to give a friendly message. It\njust felt silly to force sites to create the directory only to\nrefuse an access to the \"custom commands\" feature, especially when\nthe existence of that directory is a signal that the site may want\nto give its users an acess to that feature.\n"},{"id":"209222","messageId":"7vhaljpbpn.fsf@alter.siamese.dyndns.org","threadId":"32875","inReplyTo":"20130211055752.GF15329@elie.Belkin","subject":"Re: [PATCH 1/2] shell doc: emphasize purpose and security model","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-11T07:10:44Z","receivedAt":"2013-02-11T07:10:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> diff --git a/Documentation/git-shell.txt b/Documentation/git-shell.txt\n> index 9b925060..4fe93203 100644\n> --- a/Documentation/git-shell.txt\n> +++ b/Documentation/git-shell.txt\n> @@ -9,25 +9,61 @@ git-shell - Restricted login shell for Git-only SSH access\n> SYNOPSIS\n> --------\n> [verse]\n> -'git shell' [-c ]\n> +'chsh' -s $(which git-shell) git\n\n\nPlease don't use \"which\" in scripts. Perhaps \"command -v\" is more\nsuitable here.\n\n\nOtherwise looks good to me. Thanks.\n\n> +'git clone' `git@localhost:/path/to/repo.git`\n> +'ssh' `git@localhost`\n> \n> DESCRIPTION\n> -----------\n> \n> +This is a login shell for SSH accounts to provide restricted Git access.\n> +It permits execution only of server-side Git commands implementing the\n> +pull/push functionality, plus custom commands present in a subdirectory\n> +named `git-shell-commands` in the user's home directory.\n> +\n> +COMMANDS\n> +--------\n> +\n> +'git shell' accepts the following commands after the '-c' option:\n> +\n> +'git receive-pack '::\n> +'git upload-pack '::\n> +'git upload-archive '::\n> +\tCall the corresponding server-side command to support\n> +\tthe client's 'git push', 'git fetch', or 'git archive --remote'\n> +\trequest.\n> +'cvs server'::\n> +\tImitate a CVS server. See linkgit:git-cvsserver[1].\n> +\n> +If a `~/git-shell-commands` directory is present, 'git shell' will\n> +also handle other, custom commands by running\n> +\"`git-shell-commands/ `\" from the user's home\n> +directory.\n> +\n> +INTERACTIVE USE\n> +---------------\n> +\n> +By default, the commands above can be executed only with the '-c'\n> +option; the shell is not interactive.\n> +\n> +If a `~/git-shell-commands` directory is present, 'git shell'\n> +can also be run interactively (with no arguments). If a `help`\n> +command is present in the `git-shell-commands` directory, it is\n> +run to provide the user with an overview of allowed actions. Then a\n> +\"`git> `\" prompt is presented at which one can enter any of the\n> +commands from the `git-shell-commands` directory, or `exit` to close\n> +the connection.\n> +\n> +Generally this mode is used as an administrative interface to allow\n> +users to list repositories they have access to, create, delete, or\n> +rename repositories, or change repository descriptions and\n> +permissions.\n> +\n> +SEE ALSO\n> +--------\n> +ssh(1),\n> +linkgit:git-daemon[1],\n> +contrib/git-shell-commands/README\n> \n> GIT\n> ---\n"},{"id":"209223","messageId":"20130211071235.GL15329@elie.Belkin","threadId":"32875","inReplyTo":"7vliavpc4q.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-02-11T07:12:35Z","receivedAt":"2013-02-11T07:12:35Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n> Jonathan Nieder writes:\n\n>> The trouble is that I can't imagine a canned message that everyone\n>> will like. (For example, I quite dislike the current one.) That's\n>> exactly the situation in which some configurability is helpful.\n>\n> I am not saying we should have a perfect canned message everybody\n> likes and not have any configurability. I however think we can aim\n> to come up with a message that covers 80% of site administrators who\n> do not care too much and just want git-shell to allow the standard\n> services without giving any custom command.\n\nIsn't the current message meant to be that? Just removing the \"hint:\"\nline would be enough to leave me happy with it.\n\n> And for the remaining 20% of those who do not like the canned\n> message but still do not need any custom command, I think it is way\n> suboptimal to force them to create git-shell-commands directory for\n> 47 users his host gives git-shell access to, and copy the \"help\"\n> script to all of them, only to get a customized message.\n\nIsn't that a criticism of the git-shell-commands facility in general?\nIf it is common to have a lot of users with distinct home directories\nbut all with git-shell as their login shell, then the\ngit-shell-commands should not go in their home directory to begin\nwith, no?\n\nI think sharing a home directory is fine and the normal thing to do\nwith such a restricted account, fwiw, so I am not the one to guess\nwhat people who do something different would find most useful. Maybe\nI am not the right person to have proposed this patch in the first\nplace --- I saw something that looked wrong and proposed what I\nthought was a reasonable fix, but I am not actively depending on\ngit-shell myself, so...\n\n*shrug*\n\nHope that helps,\nJonathan\n"},{"id":"209224","messageId":"20130211071358.GM15329@elie.Belkin","threadId":"32875","inReplyTo":"7vhaljpbpn.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1/2] shell doc: emphasize purpose and security model","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-02-11T07:13:58Z","receivedAt":"2013-02-11T07:13:58Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n> Jonathan Nieder writes:\n\n>> --- a/Documentation/git-shell.txt\n>> +++ b/Documentation/git-shell.txt\n>> @@ -9,25 +9,61 @@ git-shell - Restricted login shell for Git-only SSH access\n>> SYNOPSIS\n>> --------\n>> [verse]\n>> -'git shell' [-c ]\n>> +'chsh' -s $(which git-shell) git\n[...]\n> \"command -v\"\n\nSounds good.\n\n(chsh isn't in POSIX either, FWIW. ;-))\n\nJonathan\n"},{"id":"209225","messageId":"7vd2w7pbh5.fsf@alter.siamese.dyndns.org","threadId":"32875","inReplyTo":"20130211055847.GG15329@elie.Belkin","subject":"Re: [PATCH 2/2] shell: pay attention to exit status from 'help' command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-11T07:15:50Z","receivedAt":"2013-02-11T07:15:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> diff --git a/Documentation/git-shell.txt b/Documentation/git-shell.txt\n> index 4fe93203..60051e63 100644\n> --- a/Documentation/git-shell.txt\n> +++ b/Documentation/git-shell.txt\n> @@ -59,6 +59,26 @@ users to list repositories they have access to, create, delete, or\n> rename repositories, or change repository descriptions and\n> permissions.\n> \n> +If the `help` command exists and exits with nonzero status, the\n> +interactive shell is aborted.\n> +\n> +EXAMPLE\n> +-------\n> +\n> +To disable interactive logins, displaying a greeting instead:\n> ++\n> +----------------\n> +$ chsh -s /usr/bin/git-shell\n> +$ mkdir $HOME/git-shell-commands\n> +$ cat >$HOME/git-shell-commands/help <<\\EOF\n> +#!/bin/sh\n> +printf '%s\\n' \"Hi $USER! You've successfully authenticated, but I do not\"\n\nWhere in the sshd to git-shell exec chain is $USER variable set for\nthe user? Just being curious if this is the simplest but one of the\nmore robust ways to get the user's name.\n\nI still think forcing the site administrator create a directory for\neach and every user only to house a single script that denies the\naccess is a wrong design, but the code seems to correctly implement\nthat design.\n"},{"id":"209226","messageId":"CAE_TNi=EG6vziVObJ-a__smeOv7RgZ5R146eonD6M828H7ziNQ@mail.gmail.com","threadId":"32875","inReplyTo":"7vliavpc4q.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Ethan Reesor","fromEmail":"firelizzard@gmail.com","sentAt":"2013-02-11T07:15:51Z","receivedAt":"2013-02-11T07:15:51Z","isPatch":true,"sender":{"key":"firelizzard@gmail.com","avatar":"https://gravatar.com/avatar/65a178b01509a9c779e386b21651ed62eae41049adb69ed4ac31ea4a4dbdcd98?d=mp&s=160"},"body":"On Mon, Feb 11, 2013 at 2:01 AM, Junio C Hamano wrote:\n> And for the remaining 20% of those who do not like the canned\n> message but still do not need any custom command, I think it is way\n> suboptimal to force them to create git-shell-commands directory for\n> 47 users his host gives git-shell access to, and copy the \"help\"\n> script to all of them, only to get a customized message. It would\n> help them quite a lot if you just called /etc/git/shell-disabled or\n> some hook that generates a customized message; then there is no need\n> to add any git-shell-commands directory and a \"help\" script every\n> time he gets one new user, no?\n>\n> For those who _do_ want to give customized commands to their users,\n> they can already have \"help\" script to give a friendly message. It\n> just felt silly to force sites to create the directory only to\n> refuse an access to the \"custom commands\" feature, especially when\n> the existence of that directory is a signal that the site may want\n> to give its users an acess to that feature.\n\nAgain, would it not be more elegant and powerful to A) have the\nshell-disabled message/hook/etc specified by git-config on some level,\nbe it /etc/gitconfig or ~/.gitconfig, and B) have Jonathan's patch\nwhereby ~/git-shell-commands/help returning non-zero closes the\nconnection? Have shell.c read for settings in the pattern:\n [shell \"disabled\"]\n message = \"Hi, this is your server speaking. I've\nreplaced the usual message.\"\n command = \"/path/to/some/command\"\nIf shell.disabled.command is defined, don't bother with the message.\nIf it is not, but shell.disabled.message is, display that. If neither\nof them are, display the default message, and make that one more\nfriendly.\n\nEven if that was implemented, there is still an argument for\nJonathan's patch. For example, I'm building a server where\n~/git-shell-commands/help does something interesting. But sometimes,\nsomething fails. When that something fails, I want to close the\nconnection for whatever reason.\n\nSo, any reason not to have both (on top of making a better default message)?\n\n--\nEthan Reesor (Gmail)\n"},{"id":"209227","messageId":"7v8v6vpbej.fsf@alter.siamese.dyndns.org","threadId":"32875","inReplyTo":"20130211071235.GL15329@elie.Belkin","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-11T07:17:24Z","receivedAt":"2013-02-11T07:17:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Isn't that a criticism of the git-shell-commands facility in general?\n> If it is common to have a lot of users with distinct home directories\n> but all with git-shell as their login shell, then the\n> git-shell-commands should not go in their home directory to begin\n> with, no?\n\nYou can give one set of commands to some users while restricting\nothers, no?\n"},{"id":"209228","messageId":"CAE_TNim1eJpbpdYFVikk8e73i1oAmG+yqLK+tAomLoEm+ytzeQ@mail.gmail.com","threadId":"32875","inReplyTo":"20130211071235.GL15329@elie.Belkin","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Ethan Reesor","fromEmail":"firelizzard@gmail.com","sentAt":"2013-02-11T07:18:38Z","receivedAt":"2013-02-11T07:18:38Z","isPatch":true,"sender":{"key":"firelizzard@gmail.com","avatar":"https://gravatar.com/avatar/65a178b01509a9c779e386b21651ed62eae41049adb69ed4ac31ea4a4dbdcd98?d=mp&s=160"},"body":"On Mon, Feb 11, 2013 at 2:12 AM, Jonathan Nieder wrote:\n> Isn't that a criticism of the git-shell-commands facility in general?\n> If it is common to have a lot of users with distinct home directories\n> but all with git-shell as their login shell, then the\n> git-shell-commands should not go in their home directory to begin\n> with, no?\n\nI know nothing of the security issues, but why not have a\n/etc/git-shell-commands?\n\n-- \nEthan Reesor (Gmail)\n"},{"id":"209229","messageId":"20130211072154.GN15329@elie.Belkin","threadId":"32875","inReplyTo":"7v8v6vpbej.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-02-11T07:21:54Z","receivedAt":"2013-02-11T07:21:54Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n> Jonathan Nieder writes:\n\n>> Isn't that a criticism of the git-shell-commands facility in general?\n>> If it is common to have a lot of users with distinct home directories\n>> but all with git-shell as their login shell, then the\n>> git-shell-commands should not go in their home directory to begin\n>> with, no?\n>\n> You can give one set of commands to some users while restricting\n> others, no?\n\nYes, I assume one goal of the current design was to let you set up\nmultiple configurations by making multiple home directories.\n"},{"id":"209230","messageId":"7v4nhjpb69.fsf@alter.siamese.dyndns.org","threadId":"32875","inReplyTo":"CAE_TNi=EG6vziVObJ-a__smeOv7RgZ5R146eonD6M828H7ziNQ@mail.gmail.com","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-11T07:22:22Z","receivedAt":"2013-02-11T07:22:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ethan Reesor writes:\n\n>> For those who _do_ want to give customized commands to their users,\n>> they can already have \"help\" script to give a friendly message. It\n>> just felt silly to force sites to create the directory only to\n>> refuse an access to the \"custom commands\" feature, especially when\n>> the existence of that directory is a signal that the site may want\n>> to give its users an acess to that feature.\n>\n> Again, would it not be more elegant and powerful to A) have the\n> shell-disabled message/hook/etc specified by git-config on some level,\n> be it /etc/gitconfig or ~/.gitconfig, and B) have Jonathan's patch\n> whereby ~/git-shell-commands/help returning non-zero closes the\n> connection?\n\nIsn't that what I have essentially been saying?\n\nFor sites that do not want per-user customizable \"other commands\",\nhave a single site-wide hook instead of having to create otherwise\nempty shell-commands directories for all users. For users a site\nwants to allow customized commands, have the directory and custom\n\"help\" message. I do not care too deeply if \"help\" exiting non-zero\ncaused the connection closed, but I care about not forcing a lot of\neffort to customize messages to people who do *not* need\ncustomizability.\n"},{"id":"209231","messageId":"CAE_TNin+WcPodGfXKQuzBVujK7Yx3iCUR2rqgoc20WgwhJSR4g@mail.gmail.com","threadId":"32875","inReplyTo":"7v4nhjpb69.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Ethan Reesor","fromEmail":"firelizzard@gmail.com","sentAt":"2013-02-11T07:26:02Z","receivedAt":"2013-02-11T07:26:02Z","isPatch":true,"sender":{"key":"firelizzard@gmail.com","avatar":"https://gravatar.com/avatar/65a178b01509a9c779e386b21651ed62eae41049adb69ed4ac31ea4a4dbdcd98?d=mp&s=160"},"body":"On Mon, Feb 11, 2013 at 2:22 AM, Junio C Hamano wrote:\n> Ethan Reesor writes:\n>> Again, would it not be more elegant and powerful to A) have the\n>> shell-disabled message/hook/etc specified by git-config on some level,\n>> be it /etc/gitconfig or ~/.gitconfig, and B) have Jonathan's patch\n>> whereby ~/git-shell-commands/help returning non-zero closes the\n>> connection?\n>\n> Isn't that what I have essentially been saying?\n\nThat is what you've been saying. I reiterated because I like the idea\nof having it managed via git config.\n"},{"id":"209232","messageId":"7vzjzbnwb7.fsf@alter.siamese.dyndns.org","threadId":"32875","inReplyTo":"CAE_TNin+WcPodGfXKQuzBVujK7Yx3iCUR2rqgoc20WgwhJSR4g@mail.gmail.com","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-11T07:28:44Z","receivedAt":"2013-02-11T07:28:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ethan Reesor writes:\n\n> On Mon, Feb 11, 2013 at 2:22 AM, Junio C Hamano wrote:\n>> Ethan Reesor writes:\n>>> Again, would it not be more elegant and powerful to A) have the\n>>> shell-disabled message/hook/etc specified by git-config on some level,\n>>> be it /etc/gitconfig or ~/.gitconfig, and B) have Jonathan's patch\n>>> whereby ~/git-shell-commands/help returning non-zero closes the\n>>> connection?\n>>\n>> Isn't that what I have essentially been saying?\n>\n> That is what you've been saying. I reiterated because I like the idea\n> of having it managed via git config.\n\nYes, and I've been ignoring the \"git config\". I do not think it\ngives enough customizability Jonathan's example of listing user\nowned repositories, for example. Having a config variable in\n/etc/gitconfig that points at a random script on the filesystem does\nnot buy us much over an approach to have a global hook at a known\nplace on the filesystem, no?\n"},{"id":"209233","messageId":"7vvc9znvk6.fsf@alter.siamese.dyndns.org","threadId":"32875","inReplyTo":"20130211072154.GN15329@elie.Belkin","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-11T07:44:57Z","receivedAt":"2013-02-11T07:44:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Junio C Hamano wrote:\n>> Jonathan Nieder writes:\n>\n>>> Isn't that a criticism of the git-shell-commands facility in general?\n>>> If it is common to have a lot of users with distinct home directories\n>>> but all with git-shell as their login shell, then the\n>>> git-shell-commands should not go in their home directory to begin\n>>> with, no?\n>>\n>> You can give one set of commands to some users while restricting\n>> others, no?\n>\n> Yes, I assume one goal of the current design was to let you set up\n> multiple configurations by making multiple home directories.\n\nEven if the site configures its 47 git-shell users to share the same\nhome directory /home/gituser, I still think it is a bad design to\nforce the administrator to create a directory in it, only to add a\nscript called \"help\".\n\nThe purpose of the directory is to keep custom commands that are\nallowed. If the site administrator does not want any command, it\nwould be more natural to expect that the way to disable them would\nbe _not_ to have that directory which is a collection of allowed\ncommands. Adding that directory and add a \"help\" that exits with\nnon-zero feels quite a roundabout and counter-intuitive way, no?\n"},{"id":"209235","messageId":"20130211075245.GO15329@elie.Belkin","threadId":"32875","inReplyTo":"7vd2w7pbh5.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 2/2] shell: pay attention to exit status from 'help' command","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-02-11T07:52:45Z","receivedAt":"2013-02-11T07:52:45Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n> Jonathan Nieder writes:\n\n>> +To disable interactive logins, displaying a greeting instead:\n>> ++\n>> +----------------\n>> +$ chsh -s /usr/bin/git-shell\n>> +$ mkdir $HOME/git-shell-commands\n>> +$ cat >$HOME/git-shell-commands/help <<\\EOF\n>> +#!/bin/sh\n>> +printf '%s\\n' \"Hi $USER! You've successfully authenticated, but I do not\"\n>\n> Where in the sshd to git-shell exec chain is $USER variable set for\n> the user? Just being curious if this is the simplest but one of the\n> more robust ways to get the user's name.\n\nThat's a good question. environment= in an authorized_keys file is\nobsolete, so USER generally represents the actual logged in user.\n\nThat means the main way to base behavior on private key (letting one\nsystem user represent multiple people) is a gitolite-style command=\nwrapper that checks SSH_ORIGINAL_COMMAND. In that setup, there is no\nreason to forward simple no-args \"are you there?\" requests to the\ngit-shell, so we can forget about it here.\n\nSo by the time we get to git-shell, most likely either\n\n A) this is a generic system user, with a username like \"git\", and the\n above example would insult the client with \"Hi git!\" or \"Hi\n project-x-git!\"\n\nor\n\n B) each person has a separate account on the system, perhaps to help\n the admin to set filesystem permissions based on users and groups,\n and the above would address the user by her normal name.\n\nJonathan\n"},{"id":"209238","messageId":"20130211081346.GP15329@elie.Belkin","threadId":"32875","inReplyTo":"7vvc9znvk6.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-02-11T08:13:46Z","receivedAt":"2013-02-11T08:13:46Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n> The purpose of the directory is to keep custom commands that are\n> allowed. If the site administrator does not want any command, it\n> would be more natural to expect that the way to disable them would\n> be _not_ to have that directory which is a collection of allowed\n> commands. Adding that directory and add a \"help\" that exits with\n> non-zero feels quite a roundabout and counter-intuitive way, no?\n\nI think it comes down to the reason the site admin doesn't want to\nallow interactive logins. That reason seems to be mostly that\npresenting a\n\n\tgit>\n\nprompt at which you can only ask for \"help\" or \"exit\" is a bit\nconfusing and pointless. I have sympathy for that, which is why I\nlooked for a way for the admin to ask to avoid the prompt altogether\nin that case.\n\nI do not think the reason is \"because I don't want a\ngit-shell-commands directory\". I think it's good to have basically\none kind of setup instead of significantly different ones with and\nwithout that special directory --- and it means that starting from a\nsetup like this, one can easily drop in additional commands like\nset-head or create-repo without changing anything basic. It's making\nthe admin's later life easier.\n\nMaybe a better test than \"help exits with special exit code\" is \"there\nare no other custom commands than help\". Would that be more sensible?\n\n>From a \"make it possible to emulate gitolite\" point of view, that\ndoesn't permit disabling the interactive mode when there are other\ncommands available, so my hunch is that it wouldn't.\n\nJonathan\n"},{"id":"209252","messageId":"20130211160057.GA16402@sigill.intra.peff.net","threadId":"32875","inReplyTo":"7v8v6vpbej.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-02-11T16:00:57Z","receivedAt":"2013-02-11T16:00:57Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 10, 2013 at 11:17:24PM -0800, Junio C Hamano wrote:\n\n> Jonathan Nieder writes:\n> \n> > Isn't that a criticism of the git-shell-commands facility in general?\n> > If it is common to have a lot of users with distinct home directories\n> > but all with git-shell as their login shell, then the\n> > git-shell-commands should not go in their home directory to begin\n> > with, no?\n> \n> You can give one set of commands to some users while restricting\n> others, no?\n\nBut that seems to me to argue against /etc/git/shell-disabled or\nsimilar, which would apply to every user. Or are you proposing that the\ncheck be:\n\n if -d ~/git-shell-commands; then\n : ok, interactive\n elif -x /etc/git/shell-disabled; then\n exec /etc/git/shell-disabled\n else\n echo >&2 'go away'\n exit 1\n fi\n\nThat at least means you can apply _whether_ to disable the shell\nselectively for each user (by providing or not a git-shell-commands\ndirectory), but you cannot individually select the script that runs for\nthat user. But it's probably still flexible enough; you can, after all, run\narbitrary code in the shell-disabled script, so it can select which\nclass of user it was called on and dispatch to a sub-script.\n\n-Peff\n"},{"id":"209254","messageId":"7vmwvaomdx.fsf@alter.siamese.dyndns.org","threadId":"32875","inReplyTo":"20130211081346.GP15329@elie.Belkin","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-11T16:17:46Z","receivedAt":"2013-02-11T16:17:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Junio C Hamano wrote:\n>\n>> The purpose of the directory is to keep custom commands that are\n>> allowed. If the site administrator does not want any command, it\n>> would be more natural to expect that the way to disable them would\n>> be _not_ to have that directory which is a collection of allowed\n>> commands. Adding that directory and add a \"help\" that exits with\n>> non-zero feels quite a roundabout and counter-intuitive way, no?\n>\n> I think it comes down to the reason the site admin doesn't want to\n> allow interactive logins. That reason seems to be mostly that\n> presenting a\n>\n> \tgit>\n>\n> prompt at which you can only ask for \"help\" or \"exit\" is a bit\n> confusing and pointless. I have sympathy for that, which is why I\n> looked for a way for the admin to ask to avoid the prompt altogether\n> in that case.\n\nYeah, the prompt does look pointless.\n\n> I do not think the reason is \"because I don't want a\n> git-shell-commands directory\". I think it's good to have basically\n> one kind of setup instead of significantly different ones with and\n> without that special directory --- and it means that starting from a\n> setup like this, one can easily drop in additional commands like\n> set-head or create-repo without changing anything basic. It's making\n> the admin's later life easier.\n\nI do not think I follow. If the admin wants to eventually have\nextra commands supported at the site, but not yet ready to do so,\nisn't it more natural to start with a less elaborate configuration\n(i.e. without the directory) now and then add the directory when the\nsite is ready for offering extra commands later?\n\n> Maybe a better test than \"help exits with special exit code\" is \"there\n> are no other custom commands than help\". Would that be more sensible?\n>\n> From a \"make it possible to emulate gitolite\" point of view, that\n> doesn't permit disabling the interactive mode when there are other\n> commands available, so my hunch is that it wouldn't.\n\nA paragraph I had in the message you are responding to before I sent\nit out (but removed because it felt somewhat offtopic) said \"if the\nmechanism to disable weren't the magic 'help exited with failure'\nbut 'an interactive-disabled flag file exists there', I may find it\nless strange to have the directory there\", or something like that.\n\nAnd that flag file could be a custom script that gives a custom\nmessage.\n"},{"id":"209263","messageId":"7vip5yolvo.fsf@alter.siamese.dyndns.org","threadId":"32875","inReplyTo":"20130211075245.GO15329@elie.Belkin","subject":"Re: [PATCH 2/2] shell: pay attention to exit status from 'help' command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-11T16:28:43Z","receivedAt":"2013-02-11T16:28:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Junio C Hamano wrote:\n>> Jonathan Nieder writes:\n>\n>>> +To disable interactive logins, displaying a greeting instead:\n>>> ++\n>>> +----------------\n>>> +$ chsh -s /usr/bin/git-shell\n>>> +$ mkdir $HOME/git-shell-commands\n>>> +$ cat >$HOME/git-shell-commands/help <<\\EOF\n>>> +#!/bin/sh\n>>> +printf '%s\\n' \"Hi $USER! You've successfully authenticated, but I do not\"\n>>\n>> Where in the sshd to git-shell exec chain is $USER variable set for\n>> the user? Just being curious if this is the simplest but one of the\n>> more robust ways to get the user's name.\n>\n> That's a good question. environment= in an authorized_keys file is\n> obsolete, so USER generally represents the actual logged in user.\n>\n> That means the main way to base behavior on private key (letting one\n> system user represent multiple people) is a gitolite-style command=\n> wrapper that checks SSH_ORIGINAL_COMMAND. In that setup, there is no\n> reason to forward simple no-args \"are you there?\" requests to the\n> git-shell, so we can forget about it here.\n>\n> So by the time we get to git-shell, most likely either\n>\n> A) this is a generic system user, with a username like \"git\", and the\n> above example would insult the client with \"Hi git!\" or \"Hi\n> project-x-git!\"\n>\n> or\n>\n> B) each person has a separate account on the system, perhaps to help\n> the admin to set filesystem permissions based on users and groups,\n> and the above would address the user by her normal name.\n\nWhat return value getuid(2) would give us was not something I was\nworried about. Use of git-shell would be pointless if that does not\nwork to offer isolation between users.\n\nI was wondering who would set the $USER variable based on the uid\nassigned to the process during the remote login process and it is a\nbehaviour we can rely on across platforms. It appears that when\ncoming over ssh, it is the ssh daemon that sets USER (and LOGNAME,\nHOME, etc.) before running the login shell (session.c::do_child()\nthat is called from do_exec_pty() or do_exec_no_pty() in openssh).\n"},{"id":"209276","messageId":"7v38x2ojl1.fsf@alter.siamese.dyndns.org","threadId":"32875","inReplyTo":"20130211160057.GA16402@sigill.intra.peff.net","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-11T17:18:18Z","receivedAt":"2013-02-11T17:18:18Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Sun, Feb 10, 2013 at 11:17:24PM -0800, Junio C Hamano wrote:\n>\n>> Jonathan Nieder writes:\n>> \n>> > Isn't that a criticism of the git-shell-commands facility in general?\n>> > If it is common to have a lot of users with distinct home directories\n>> > but all with git-shell as their login shell, then the\n>> > git-shell-commands should not go in their home directory to begin\n>> > with, no?\n>> \n>> You can give one set of commands to some users while restricting\n>> others, no?\n>\n> But that seems to me to argue against /etc/git/shell-disabled or\n> similar, which would apply to every user. Or are you proposing that the\n> check be:\n>\n> if -d ~/git-shell-commands; then\n> : ok, interactive\n> elif -x /etc/git/shell-disabled; then\n> exec /etc/git/shell-disabled\n> else\n> echo >&2 'go away'\n> exit 1\n> fi\n\nThat \"shell-disabled\" thing was to allow customizing the existing\ndie() that triggers here:\n\n\t} else if (argc == 1) {\n\t\t/* Allow the user to run an interactive shell */\n\t\tcd_to_homedir();\n\t\tif (access(COMMAND_DIR, R_OK | X_OK) == -1) {\n\t\t\tdie(\"Interactive git shell is not enabled.\\n\"\n\t\t\t \"hint: ~/\" COMMAND_DIR \" should exist \"\n\t\t\t \"and have read and execute access.\");\n\t\t}\n\t\trun_shell();\n\t\texit(0);\n\nso it is more like\n\n\tif ! test -d $HOME/git-shell-commands\n\tthen\n\t\tif test -x /etc/git/shell-disabled\n then\n\t\t\texec /etc/git/shell-disabled\n\t\telse\n\t\t\tdie Interactive is not enabled\n\t\tfi\n\tfi\n ... do whatever in run_shell() ...\n\n\n> That at least means you can apply _whether_ to disable the shell\n> selectively for each user (by providing or not a git-shell-commands\n> directory), but you cannot individually select the script that runs for\n> that user. But it's probably still flexible enough;...\n\nSuch a flexibility is not a goal of /etc/git/shell-disabled. The\nsole goal is to make the life easier for those site owners that do\nnot want any interactive shell access to give more friendly and\ncustomized error message.\n\nThose who want further flexibility can exit with non-zero from the\n\"help\" (which is still a misnomer for a hook to disable interactive\nfor the user).\n\nMy primary objection is that implementing only that \"more flexible\nbut requires more configuration work\" solution without giving\nsimpler solution (i.e. just one thing to configure) to the majory of\nsite owners who only have simpler problem to solve (i.e. just want\nto customize \"no interactive here\"), and saying that the latter can\nbe done on top. It is backwards mentality.\n"},{"id":"209280","messageId":"20130211172752.GH16402@sigill.intra.peff.net","threadId":"32875","inReplyTo":"7v38x2ojl1.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH] shell: allow 'help' command to disable interactive shell","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-02-11T17:27:52Z","receivedAt":"2013-02-11T17:27:52Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 11, 2013 at 09:18:18AM -0800, Junio C Hamano wrote:\n\n> That \"shell-disabled\" thing was to allow customizing the existing\n> die() that triggers here:\n> [...]\n> so it is more like\n> \n> \tif ! test -d $HOME/git-shell-commands\n> \tthen\n> \t\tif test -x /etc/git/shell-disabled\n> then\n> \t\t\texec /etc/git/shell-disabled\n> \t\telse\n> \t\t\tdie Interactive is not enabled\n> \t\tfi\n> \tfi\n> ... do whatever in run_shell() ...\n\nOK, that is equivalent to what I said (or at least what I was trying to\nsay :) ).\n\n> > That at least means you can apply _whether_ to disable the shell\n> > selectively for each user (by providing or not a git-shell-commands\n> > directory), but you cannot individually select the script that runs for\n> > that user. But it's probably still flexible enough;...\n> \n> Such a flexibility is not a goal of /etc/git/shell-disabled. The\n> sole goal is to make the life easier for those site owners that do\n> not want any interactive shell access to give more friendly and\n> customized error message.\n> \n> Those who want further flexibility can exit with non-zero from the\n> \"help\" (which is still a misnomer for a hook to disable interactive\n> for the user).\n\nAh, I thought you were proposing shell-disabled _instead_ of Jonathan's\npatch, not in addition to.\n\n> My primary objection is that implementing only that \"more flexible\n> but requires more configuration work\" solution without giving\n> simpler solution (i.e. just one thing to configure) to the majory of\n> site owners who only have simpler problem to solve (i.e. just want\n> to customize \"no interactive here\"), and saying that the latter can\n> be done on top. It is backwards mentality.\n\nOh, absolutely. The easy case should be easy, and the hard case\npossible. But another way of doing that (which would also make life\neasier for admins who want to share config besides shell-disabled) would\nbe:\n\n 1. Give Jonathan's magic meaning to ~/git-shell-commands/help's exit\n code.\n\n 2. Make /etc/git/shell-commands a fallback if ~/git-shell-commands\n does not exist.\n\nThat turns your /etc/git/shell-disabled into /etc/git/shell-commands/help.\nIt is just as simple to do a site-wide change, still allows per-user\noverrides, and additionally gives people who _do_ want the interactive\ncommands the ability to configure them site-wide instead of symlinking a\ndirectory into everybody's homedir.\n\nThe only downside is that it has the confusing \"create this directory to\nturn on interactivity, then create a file in it to turn it back off\"\nfeature.\n\nI admit I don't care too much, though. I have never actually used\ngit-shell, as my systems are all either too small (i.e., users are\ntrusted and have shell access) or too big (grown well beyond a single\nserver that connects users straight to git-shell). In fact, there seems\nto be a lot of guessing in this thread about what people would want, as\nit seems none of us actually uses the feature. Maybe that is a sign it\nis being over-engineered. :)\n\n-Peff\n"},{"id":"209287","messageId":"7vliaun1kg.fsf@alter.siamese.dyndns.org","threadId":"32875","inReplyTo":"20130211055752.GF15329@elie.Belkin","subject":"Re: [PATCH 1/2] shell doc: emphasize purpose and security model","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-11T18:32:47Z","receivedAt":"2013-02-11T18:32:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> diff --git a/Documentation/git-shell.txt b/Documentation/git-shell.txt\n> index 9b925060..4fe93203 100644\n> --- a/Documentation/git-shell.txt\n> +++ b/Documentation/git-shell.txt\n> @@ -9,25 +9,61 @@ git-shell - Restricted login shell for Git-only SSH access\n> SYNOPSIS\n> --------\n> [verse]\n> -'git shell' [-c ]\n> +'chsh' -s $(which git-shell) git\n> +'git clone' `git@localhost:/path/to/repo.git`\n> +'ssh' `git@localhost`\n\nI am wondering if we want to do the following instead of/in addition\nto fixing the $(which git-shell). It is not like we only allow a\nsingle user and its name has to be 'git'.\n\ndiff --git a/Documentation/git-shell.txt b/Documentation/git-shell.txt\nindex 4fe9320..6829ea9 100644\n--- a/Documentation/git-shell.txt\n+++ b/Documentation/git-shell.txt\n@@ -9,9 +9,9 @@ git-shell - Restricted login shell for Git-only SSH access\n SYNOPSIS\n --------\n [verse]\n-'chsh' -s $(which git-shell) git\n-'git clone' `git@localhost:/path/to/repo.git`\n-'ssh' `git@localhost`\n+'chsh' -s /path/to/git-shell \n+'git clone' `@localhost:/path/to/repo.git`\n+'ssh' `@localhost`\n \n DESCRIPTION\n -----------\n"},{"id":"210936","messageId":"20130309215237.GA24777@elie.Belkin","threadId":"32875","inReplyTo":"CAE_TNikk-9sYVRQRwRecNpp3otQ+oc=uV9SPu+7pAkCUNbcUoQ@mail.gmail.com","subject":"[PATCH v3 0/2] shell: allow 'no-interactive-login' command to disable interactive shell","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-03-09T21:52:37Z","receivedAt":"2013-03-09T21:52:37Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi again,\n\nHere's a reroll along the lines described at\nhttp://thread.gmane.org/gmane.comp.version-control.git/216229\n\nAs before, this series is meant to give users of basic 'git shell'\nsetups a chance to imitate some nice behaviors that GitHub and\ngitolite offer in more complicated ways. Thanks for your help on it\nso far.\n\nJonathan Nieder (2):\n shell doc: emphasize purpose and security model\n shell: allow customization of \"interactive login disabled\" message\n\n Documentation/git-shell.txt | 86 +++++++++++++++++++++++++++++++++++++--------\n shell.c | 13 +++++++\n 2 files changed, 84 insertions(+), 15 deletions(-)\n"},{"id":"210937","messageId":"20130309215537.GB24777@elie.Belkin","threadId":"32875","inReplyTo":"20130309215237.GA24777@elie.Belkin","subject":"[PATCH 1/2] shell doc: emphasize purpose and security model","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-03-09T21:55:37Z","receivedAt":"2013-03-09T21:55:37Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"The original git-shell(1) manpage emphasized that the shell supports\nonly git transport commands. As the shell gained features, that\nemphasis and focus in the manual has been lost. Bring it back by\nsplitting the manpage into a few short sections and fleshing out each:\n\n - SYNOPSIS, describing how the shell gets used in practice\n - DESCRIPTION, which gives an overview of the purpose and guarantees\n provided by this restricted shell\n - COMMANDS, listing supported commands and restrictions on the\n arguments they accept\n - INTERACTIVE USE, describing the interactive mode\n\nAlso add a \"see also\" section with related reading.\n\nSigned-off-by: Jonathan Nieder \n---\nChanges since v2:\n\n - use \"command -v\" instead of \"which\" in synopsis to subtly reinforce\n good habits\n - use instead of hardcoding \"git\" username in synopsis\n - give up on typesetting \"git> \" in monospace, since the toolchain\n doesn't seem to like lonely backticks :/\n - clarify change description\n\nThe actual text is pretty much the same.\n\n Documentation/git-shell.txt | 66 ++++++++++++++++++++++++++++++++++-----------\n 1 file changed, 51 insertions(+), 15 deletions(-)\n\ndiff --git a/Documentation/git-shell.txt b/Documentation/git-shell.txt\nindex 9b925060..544b21aa 100644\n--- a/Documentation/git-shell.txt\n+++ b/Documentation/git-shell.txt\n@@ -9,25 +9,61 @@ git-shell - Restricted login shell for Git-only SSH access\n SYNOPSIS\n --------\n [verse]\n-'git shell' [-c ]\n+'chsh' -s $(command -v git-shell) \n+'git clone' `@localhost:/path/to/repo.git`\n+'ssh' `@localhost`\n \n DESCRIPTION\n -----------\n \n-A login shell for SSH accounts to provide restricted Git access. When\n-'-c' is given, the program executes non-interactively;\n- can be one of 'git receive-pack', 'git upload-pack', 'git\n-upload-archive', 'cvs server', or a command in COMMAND_DIR. The shell\n-is started in interactive mode when no arguments are given; in this\n-case, COMMAND_DIR must exist, and any of the executables in it can be\n-invoked.\n-\n-'cvs server' is a special command which executes git-cvsserver.\n-\n-COMMAND_DIR is the path \"$HOME/git-shell-commands\". The user must have\n-read and execute permissions to the directory in order to execute the\n-programs in it. The programs are executed with a cwd of $HOME, and\n- is parsed as a command-line string.\n+This is a login shell for SSH accounts to provide restricted Git access.\n+It permits execution only of server-side Git commands implementing the\n+pull/push functionality, plus custom commands present in a subdirectory\n+named `git-shell-commands` in the user's home directory.\n+\n+COMMANDS\n+--------\n+\n+'git shell' accepts the following commands after the '-c' option:\n+\n+'git receive-pack '::\n+'git upload-pack '::\n+'git upload-archive '::\n+\tCall the corresponding server-side command to support\n+\tthe client's 'git push', 'git fetch', or 'git archive --remote'\n+\trequest.\n+'cvs server'::\n+\tImitate a CVS server. See linkgit:git-cvsserver[1].\n+\n+If a `~/git-shell-commands` directory is present, 'git shell' will\n+also handle other, custom commands by running\n+\"`git-shell-commands/ `\" from the user's home\n+directory.\n+\n+INTERACTIVE USE\n+---------------\n+\n+By default, the commands above can be executed only with the '-c'\n+option; the shell is not interactive.\n+\n+If a `~/git-shell-commands` directory is present, 'git shell'\n+can also be run interactively (with no arguments). If a `help`\n+command is present in the `git-shell-commands` directory, it is\n+run to provide the user with an overview of allowed actions. Then a\n+\"git> \" prompt is presented at which one can enter any of the\n+commands from the `git-shell-commands` directory, or `exit` to close\n+the connection.\n+\n+Generally this mode is used as an administrative interface to allow\n+users to list repositories they have access to, create, delete, or\n+rename repositories, or change repository descriptions and\n+permissions.\n+\n+SEE ALSO\n+--------\n+ssh(1),\n+linkgit:git-daemon[1],\n+contrib/git-shell-commands/README\n \n GIT\n ---\n-- \n1.8.2.rc3\n"},{"id":"210938","messageId":"20130309220011.GC24777@elie.Belkin","threadId":"32875","inReplyTo":"20130309215237.GA24777@elie.Belkin","subject":"[PATCH 2/2] shell: new no-interactive-login command to print a custom message","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-03-09T22:00:11Z","receivedAt":"2013-03-09T22:00:11Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"If I disable git-shell's interactive mode by removing the\n~/git-shell-commands directory, attempts to use 'ssh' in produce a\nmessage intended for the administrator:\n\n\t$ ssh git@myserver\n\tfatal: Interactive git shell is not enabled.\n\thint: ~/git-shell-commands should exist and have read and execute access.\n\t$\n\nThat is helpful for the new admin who is wondering \"What? Why isn't\nthe git-shell I just set up working?\", but once the site setup is\ncomplete, it would be better to give the user a friendly hint that she\nis on the right track, like GitHub does.\n\n\tHi ! You've successfully authenticated, but\n\tGitHub does not provide shell access.\n\nAn appropriate greeting might even include more complex dynamic\ninformation, like gitolite's list of repositories the user has access\nto. Add support for a ~/git-shell-commands/no-interactive-login\ncommand that generates an arbitrary greeting. When the user tries to\nlog in:\n\n * If the file ~/git-shell-commands/no-interactive-login exists,\n run no-interactive-login to let the server say what it likes,\n then hang up.\n\n * Otherwise, if ~/git-shell-commands/ is present, start an\n interactive read-eval-print loop.\n\n * Otherwise, print the usual configuration hint and hang up.\n\nReported-by: Ethan Reesor \nSigned-off-by: Jonathan Nieder \nImproved-by: Jeff King \n---\nv2 jammed this functionality into the \"help\" command, which was kind\nof silly. Hopefully this version's better.\n\nThis is not urgent at all. If it looks like a good change, I'd be\nhappy to see it be a part of the 1.8.3 cycle.\n\nThoughts?\nJonathan\n\n Documentation/git-shell.txt | 20 ++++++++++++++++++++\n shell.c | 13 +++++++++++++\n 2 files changed, 33 insertions(+)\n\ndiff --git a/Documentation/git-shell.txt b/Documentation/git-shell.txt\nindex 544b21aa..c35051ba 100644\n--- a/Documentation/git-shell.txt\n+++ b/Documentation/git-shell.txt\n@@ -59,6 +59,26 @@ users to list repositories they have access to, create, delete, or\n rename repositories, or change repository descriptions and\n permissions.\n \n+If a `no-interactive-login` command exists, then it is run and the\n+interactive shell is aborted.\n+\n+EXAMPLE\n+-------\n+\n+To disable interactive logins, displaying a greeting instead:\n++\n+----------------\n+$ chsh -s /usr/bin/git-shell\n+$ mkdir $HOME/git-shell-commands\n+$ cat >$HOME/git-shell-commands/no-interactive-login <<\\EOF\n+#!/bin/sh\n+printf '%s\\n' \"Hi $USER! You've successfully authenticated, but I do not\"\n+printf '%s\\n' \"provide interactive shell access.\"\n+exit 128\n+EOF\n+$ chmod +x $HOME/git-shell-commands/no-interactive-login\n+----------------\n+\n SEE ALSO\n --------\n ssh(1),\ndiff --git a/shell.c b/shell.c\nindex 84b237fe..1429870a 100644\n--- a/shell.c\n+++ b/shell.c\n@@ -6,6 +6,7 @@\n \n #define COMMAND_DIR \"git-shell-commands\"\n #define HELP_COMMAND COMMAND_DIR \"/help\"\n+#define NOLOGIN_COMMAND COMMAND_DIR \"/no-interactive-login\"\n \n static int do_generic_cmd(const char *me, char *arg)\n {\n@@ -65,6 +66,18 @@ static void run_shell(void)\n {\n \tint done = 0;\n \tstatic const char *help_argv[] = { HELP_COMMAND, NULL };\n+\n+\tif (!access(NOLOGIN_COMMAND, F_OK)) {\n+\t\t/* Interactive login disabled. */\n+\t\tconst char *argv[] = { NOLOGIN_COMMAND, NULL };\n+\t\tint status;\n+\n+\t\tstatus = run_command_v_opt(argv, 0);\n+\t\tif (status < 0)\n+\t\t\texit(127);\n+\t\texit(status);\n+\t}\n+\n \t/* Print help if enabled */\n \trun_command_v_opt(help_argv, RUN_SILENT_EXEC_FAILURE);\n \n-- \n1.8.2.rc3\n"},{"id":"210948","messageId":"7v38w3etfw.fsf@alter.siamese.dyndns.org","threadId":"32875","inReplyTo":"20130309220011.GC24777@elie.Belkin","subject":"Re: [PATCH 2/2] shell: new no-interactive-login command to print a custom message","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-10T05:04:51Z","receivedAt":"2013-03-10T05:04:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> If I disable git-shell's interactive mode by removing the\n> ~/git-shell-commands directory, attempts to use 'ssh' in produce a\n> message intended for the administrator:\n\nSorry, but -ECANTPARSE. s/in produce/produces/ perhaps? Or if you\nmeant \"ssh in\" as a verb, then \"attempts to ssh in to the service\nproduces a message\". I dunno.\n\nPatch text looks good, including the documentation.\n\nThanks.\n"},{"id":"210949","messageId":"20130310052106.GA7289@elie.Belkin","threadId":"32875","inReplyTo":"7v38w3etfw.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 2/2] shell: new no-interactive-login command to print a custom message","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-03-10T05:21:06Z","receivedAt":"2013-03-10T05:21:06Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n> Jonathan Nieder writes:\n\n>> If I disable git-shell's interactive mode by removing the\n>> ~/git-shell-commands directory, attempts to use 'ssh' in produce a\n>> message intended for the administrator:\n>\n> Sorry, but -ECANTPARSE. s/in produce/produces/ perhaps? Or if you\n> meant \"ssh in\" as a verb, then \"attempts to ssh in to the service\n> produces a message\". I dunno.\n\nSloppy of me. Yes, it should say something like this:\n\n\tIf I disable git-shell's interactive mode by removing the\n\t~/git-shell-commands directory, attempts to ssh in to the service\n\tproduce a message intended for the administrator:\n"},{"id":"210966","messageId":"CALkWK0kK3YCwkv26cxVf61yUd8WHmHDG+mFwb2VRwNF3k_40qA@mail.gmail.com","threadId":"32875","inReplyTo":"20130309220011.GC24777@elie.Belkin","subject":"Re: [PATCH 2/2] shell: new no-interactive-login command to print a custom message","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-03-10T10:49:14Z","receivedAt":"2013-03-10T10:49:14Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jonathan Nieder wrote:\n> * If the file ~/git-shell-commands/no-interactive-login exists,\n> run no-interactive-login to let the server say what it likes,\n> then hang up.\n>\n> * Otherwise, if ~/git-shell-commands/ is present, start an\n> interactive read-eval-print loop.\n>\n> * Otherwise, print the usual configuration hint and hang up.\n\nExcellent. A way to suppress the ugly warning, and replace it with a\nnice message in a non-interactive shell. You've chosen\n\"no-interactive-login\" as the name of this special file, which is\nreasonable. I'm not too fond of the name \"git-shell-commands\" in the\nfirst place, but I suspect it's too late to do anything about it now.\n\n> diff --git a/shell.c b/shell.c\n> index 84b237fe..1429870a 100644\n> --- a/shell.c\n> +++ b/shell.c\n> @@ -6,6 +6,7 @@\n>\n> #define COMMAND_DIR \"git-shell-commands\"\n> #define HELP_COMMAND COMMAND_DIR \"/help\"\n> +#define NOLOGIN_COMMAND COMMAND_DIR \"/no-interactive-login\"\n>\n> static int do_generic_cmd(const char *me, char *arg)\n> {\n> @@ -65,6 +66,18 @@ static void run_shell(void)\n> {\n> int done = 0;\n> static const char *help_argv[] = { HELP_COMMAND, NULL };\n> +\n> + if (!access(NOLOGIN_COMMAND, F_OK)) {\n> + /* Interactive login disabled. */\n\nYou're just checking for its existence here, not for execute permissions.\n\n> + const char *argv[] = { NOLOGIN_COMMAND, NULL };\n> + int status;\n> +\n> + status = run_command_v_opt(argv, 0);\n\nIf \"no-interactive-login\" doesn't have execute permissions, we'll get\nan error from here:\n\n fatal: cannot exec 'git-shell-commands/no-interactive-login':\nPermission denied\n\nWould you like to check that the file has execute permission in\nadvance to prevent some extra processing (in run_command_v_opt,\nstart_command and friends) before this message is printed?\n\nLooks good otherwise.\n"},{"id":"211091","messageId":"20130311224811.GD20586@google.com","threadId":"32875","inReplyTo":"CALkWK0kK3YCwkv26cxVf61yUd8WHmHDG+mFwb2VRwNF3k_40qA@mail.gmail.com","subject":"Re: [PATCH 2/2] shell: new no-interactive-login command to print a custom message","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-03-11T22:48:11Z","receivedAt":"2013-03-11T22:48:11Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ramkumar Ramachandra wrote:\n> Jonathan Nieder wrote:\n\n>> * If the file ~/git-shell-commands/no-interactive-login exists,\n>> run no-interactive-login to let the server say what it likes,\n>> then hang up.\n[...]\n> If \"no-interactive-login\" doesn't have execute permissions, we'll get\n> an error from here:\n>\n> fatal: cannot exec 'git-shell-commands/no-interactive-login': Permission denied\n\nYep. Intended.\n\nThanks for looking it over,\nJonathan\n"},{"id":"211110","messageId":"20130312104725.GB11340@sigill.intra.peff.net","threadId":"32875","inReplyTo":"20130309215237.GA24777@elie.Belkin","subject":"Re: [PATCH v3 0/2] shell: allow 'no-interactive-login' command to disable interactive shell","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-12T10:47:25Z","receivedAt":"2013-03-12T10:47:25Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Mar 09, 2013 at 01:52:37PM -0800, Jonathan Nieder wrote:\n\n> Here's a reroll along the lines described at\n> http://thread.gmane.org/gmane.comp.version-control.git/216229\n> \n> As before, this series is meant to give users of basic 'git shell'\n> setups a chance to imitate some nice behaviors that GitHub and\n> gitolite offer in more complicated ways. Thanks for your help on it\n> so far.\n\nThanks, this version looks good to me.\n\n-Peff\n"}]}