@SHELL is now $SHELL_USERS in the rc file (warning: backward compat breakage)

Stop conflating the privilege to push changes to the admin repo with the
privilege to get a shell on the server.

Please read doc/6 carefully before upgrading to this version.  Also
please ensure that the gitolite key is *not* your only means to get a
command line on the server

conf/example.conf

@@ -246,19 +246,3 @@ repo gitolite
 # This does either a plain "git config section.key value" (for the first 3
 # examples above) or "git config --unset-all section.key" (for the last
 # example).  Other forms (--add, the value_regex, etc) are not supported.
-
-# SHELL ACCESS
-# ------------
-
-# It is possible to give certain users shell access as well as allow them to
-# use gitolite features for their git repo access.  The idea is to eliminate
-# the need for 2 keys when both shell and gitolite access are needed.
-
-# To give a user shell access, add the username to the special @SHELL group:
-
-@SHELL      =   sitaram
-
-# Do not add people to this group indiscriminately.  AUDITABILITY OF ACCESS
-# CONTROL CHANGES (AND OF REPO ACCESSES) WILL BE COMPROMISED IF ADMINS CAN
-# FIDDLE WITH THE ACTUAL (PLAIN TEXT) LOG FILES THAT GITOLITE KEEPS, WHICH
-# THEY CAN EASILY DO IF THEY HAVE A SHELL.

conf/example.gitolite.rc

@@ -93,6 +93,19 @@ $PERSONAL="";
 $GIT_PATH="";
 # $GIT_PATH="/opt/bin/";
 
+# --------------------------------------
+
+# if you want to give shell access to any gitolite user(s), name them here.
+# Please see doc/6-ssh-troubleshooting.mkd for details on how this works.
+
+# Do not add people to this list indiscriminately.  AUDITABILITY OF ACCESS
+# CONTROL CHANGES (AND OF REPO ACCESSES) WILL BE COMPROMISED IF ADMINS CAN
+# FIDDLE WITH THE ACTUAL (PLAIN TEXT) LOG FILES THAT GITOLITE KEEPS, WHICH
+# THEY CAN EASILY DO IF THEY HAVE A SHELL.
+
+# syntax: space separated list of gitolite usernames in *one* string variable.
+# $SHELL_USERS = "alice bob";
+
 # --------------------------------------
 # per perl rules, this should be the last line in such a file:
 1;

doc/6-ssh-troubleshooting.mkd

@@ -8,10 +8,34 @@ and shell access]...".  We've managed (thanks to an idea from Jesse Keating)
 to get around this.  Now it *is* possible for a single key to allow both
 gitolite access *and* shell access.
 
-This is done by placing such a user in a special `@SHELL` group in the
+This is done by:
-gitolite config file.  As usual, please see `conf/example.conf` for more info
+
-on this, since I'm using that as a central place to document anything
+  * (**on the server**) listing all such users in a variable called
-concerned with the conf file.
+    `$SHELL_USERS` in the `~/.gitolite.rc` file.  For example:
+
+        $SHELL_USERS = "alice bob";
+
+    (Note the syntax: a space separated list of users in one string variable).
+
+  * (**on your client**) make at least a dummy change to your clone of the
+    gitolite-admin repo and push it.
+
+**IMPORTANT UPGRADE NOTE**: a previous implementation of this feature worked
+by adding people to a special group (`@SHELL`) in the *config* file.  This
+meant that anyone with gitolite-admin repo write access could add himself to
+the `@SHELL` group and push, thus obtaining shell.
+
+This is not a problem for most setups, but if someone wants to separate these
+two privileges (the right to push the admin repo and the right to get a shell)
+then it does pose a problem.  Since the "rc" file can only be edited by
+someone who already has shell access, we now use that instead, even though
+this forces a change in the syntax.
+
+To migrate from the old scheme to the new one, add a new variable
+`$SHELL_USERS` to `~/.gitolite.rc` on the server with the appropriate names in
+it.  **It is best to do this directly on the server *before* upgrading to this
+version.**  (After the upgrade is done and tested you can remove the `@SHELL`
+lines from the gitolite config file).
 
 ----
 

src/gl-compile-conf

@@ -52,7 +52,7 @@ $Data::Dumper::Sortkeys = 1;
 open STDOUT, ">", "/dev/null" if (@ARGV and shift eq '-q');
 
 # these are set by the "rc" file
-our ($GL_ADMINDIR, $GL_CONF, $GL_KEYDIR, $GL_CONF_COMPILED, $REPO_BASE, $REPO_UMASK, $PROJECTS_LIST, $GIT_PATH);
+our ($GL_ADMINDIR, $GL_CONF, $GL_KEYDIR, $GL_CONF_COMPILED, $REPO_BASE, $REPO_UMASK, $PROJECTS_LIST, $GIT_PATH, $SHELL_USERS);
 # and these are set by gitolite.pm
 our ($REPONAME_PATT, $USERNAME_PATT, $AUTH_COMMAND, $AUTH_OPTIONS, $ABRT, $WARN);
 
@@ -458,7 +458,7 @@ for my $pubkey (glob("*"))
     print STDERR "WARNING: pubkey $pubkey exists but user $user not in config\n"
         unless $user_list{$user};
     $user_list{$user} = 'has pubkey';
-    if ($groups{'@SHELL'}{$user}) {
+    if ($SHELL_USERS and $SHELL_USERS =~ /(^|\s)$user(\s|$)/) {
         print $newkeys_fh "command=\"$AUTH_COMMAND -s $user\",$AUTH_OPTIONS ";
     } else {
         print $newkeys_fh "command=\"$AUTH_COMMAND $user\",$AUTH_OPTIONS,no-pty ";

src/gl-easy-install

@@ -302,12 +302,16 @@ copy_gl() {
         prompt "    ...trying to reuse existing rc" \
         "Oh hey... you already had a '.gitolite.rc' file on the server.
 Let's see if we can use that instead of the default one..."
-        sort < $tmpgli/.gitolite.rc     | perl -ne 'print "$1\n" if /^\s*(\$\w+) *=/' > $tmpgli/glrc.old
+        < $tmpgli/.gitolite.rc     perl -ne 'print "$1\n" if /^\s*(\$\w+) *=/' | sort > $tmpgli/glrc.old
-        sort < conf/example.gitolite.rc | perl -ne 'print "$1\n" if /^\s*(\$\w+) *=/' > $tmpgli/glrc.new
+        < conf/example.gitolite.rc perl -ne 'print "$1\n" if /^\s*(\$\w+) *=/' | sort > $tmpgli/glrc.new
-        if diff -u $tmpgli/glrc.old $tmpgli/glrc.new
+        comm -13 $tmpgli/glrc.old $tmpgli/glrc.new > $tmpgli/glrc.comm13
+        if [[ ! -s $tmpgli/glrc.comm13 ]]
         then
             [[ $quiet == -q ]] || ${VISUAL:-${EDITOR:-vi}} $tmpgli/.gitolite.rc
         else
+            echo new variables found in rc file:
+            cat $tmpgli/glrc.comm13
+            echo
             # MANUAL: if you're upgrading, read the instructions below and
             # manually make sure your final ~/.gitolite.rc has both your existing
             # customisations as well as any new variables that the new version of
@@ -339,6 +343,8 @@ run_install() {
     if ssh -p $port $user@$host cat $GL_ADMINDIR/conf/gitolite.conf &> /dev/null
     then
         upgrade=1
+        ssh -p $port $user@$host cat $GL_ADMINDIR/conf/gitolite.conf 2> /dev/null | grep '@SHELL' &&
+            prompt "" "$v_at_shell_bwi"
         [[ -n $admin_name ]] && echo -e "\n    *** WARNING ***: looks like an upgrade... ignoring argument '$admin_name'"
     else
         [[ -z $admin_name ]] && die "    *** ERROR ***: doesn't look like an upgrade, so I need a name for the admin"
@@ -361,7 +367,6 @@ run_install() {
 # MANUAL: setup the initial config file.  Edit $GL_ADMINDIR/conf/gitolite.conf
 # and add at least the following lines to it:
 
-#   @SHELL = sitaram
 #   repo gitolite-admin
 #       RW+                 = sitaram
 
@@ -369,8 +374,6 @@ initial_conf_key() {
     echo "#gitolite conf
 # please see conf/example.conf for details on syntax and features
 
-@SHELL                  = $admin_name
-
 repo gitolite-admin
     RW+                 = $admin_name
 
@@ -543,6 +546,17 @@ next set of command outputs coming up.  They're only relevant for a manual
 install, not this one...
 "
 
+v_at_shell_bwi="
+you are using the @SHELL feature in your gitolite config.  This feature has
+now changed in a backward incompatible way; see doc/6-ssh-troubleshooting.mkd
+for information on migrating this to the new syntax.
+
+DO NOT hit enter unless you have understood that information and properly
+migrated your setup, or you are sure you have shell access to the server
+through some other means than the $admin_name key.
+
+"
+
 v_done="
 done!