document @SHELL feature, allow "info" for all,
...but still distinguish shell folks with a small extra line telling them they have shell access
This commit is contained in:
parent
9c3abb20e1
commit
b0ce84d47f
|
@ -212,3 +212,19 @@ repo gitolite
|
||||||
# This does either a plain "git config section.key value" (for the first 3
|
# 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
|
# examples above) or "git config --unset-all section.key" (for the last
|
||||||
# example). Other forms (--add, the value_regex, etc) are not supported.
|
# 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.
|
||||||
|
|
|
@ -1,5 +1,20 @@
|
||||||
# ssh troubleshooting
|
# ssh troubleshooting
|
||||||
|
|
||||||
|
Update 2009-12-23: most of this document is now of historical interest and
|
||||||
|
will be totally revamped when I have time. For now, just note this amendment.
|
||||||
|
|
||||||
|
The document below says "we can't use the same key for both [gitolite access
|
||||||
|
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.
|
||||||
|
|
||||||
|
----
|
||||||
|
|
||||||
Ssh has always been the biggest troublespot in all this. While gitolite makes
|
Ssh has always been the biggest troublespot in all this. While gitolite makes
|
||||||
it as easy as possible, you might still run into trouble sometimes.
|
it as easy as possible, you might still run into trouble sometimes.
|
||||||
|
|
||||||
|
|
|
@ -82,8 +82,9 @@ unless ($ENV{SSH_ORIGINAL_COMMAND}) {
|
||||||
|
|
||||||
my $cmd = $ENV{SSH_ORIGINAL_COMMAND};
|
my $cmd = $ENV{SSH_ORIGINAL_COMMAND};
|
||||||
# people allowed to get a shell can get basic access info by asking nicely
|
# people allowed to get a shell can get basic access info by asking nicely
|
||||||
if ($shell_allowed and $cmd eq 'info') {
|
if ($cmd eq 'info') {
|
||||||
&report_basic($GL_ADMINDIR, $GL_CONF_COMPILED, $user);
|
&report_basic($GL_ADMINDIR, $GL_CONF_COMPILED, $user);
|
||||||
|
print "you also have shell access\n\r" if $shell_allowed;
|
||||||
exit 1;
|
exit 1;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue