@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
This commit is contained in:
Sitaram Chamarty
Sitaram Chamarty
parent
a9824464e5
commit
ecfd20e793
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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;
|
||||
|
|
|
|||
|
|
@ -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
|
||||
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
|
||||
concerned with the conf file.
|
||||
This is done by:
|
||||
|
||||
* (**on the server**) listing all such users in a variable called
|
||||
`$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).
|
||||
|
||||
----
|
||||
|
||||
|
|
|
|||
|
|
@ -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 ";
|
||||
|
|
|
|||
|
|
@ -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
|
||||
sort < conf/example.gitolite.rc | perl -ne 'print "$1\n" if /^\s*(\$\w+) *=/' > $tmpgli/glrc.new
|
||||
if diff -u $tmpgli/glrc.old $tmpgli/glrc.new
|
||||
< $tmpgli/.gitolite.rc perl -ne 'print "$1\n" if /^\s*(\$\w+) *=/' | sort > $tmpgli/glrc.old
|
||||
< conf/example.gitolite.rc perl -ne 'print "$1\n" if /^\s*(\$\w+) *=/' | sort > $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!
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue