Nico Kadel-Garcia wrote on Fri, Apr 01, 2011 at 23:46:16 -0400:
> On Fri, Apr 1, 2011 at 10:09 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> > Doesn't 'svnserve --log-file' handle this?
> >
> > Clients run 'ssh $host svnserve -t' by default, so you'd have to make
> > that invocation spawn an svnserve that has --log-file passed to it. You
> > could alter the svnserve in $PATH or use sshd configuration
> > (ForceCommand and command="" directives) to achieve that.
>
> Great. The "--log-file" option is not in the manual page. Time for a
> bug report.
>
Or a patch.
(Good catch, though.)
> Modern versions of OpenSSH (such as the version 5 in RHEL 6 and
> contemporary Debian releases) does not read your .bashrc for non-login
> sessions. (This is actually standards compliant behavior, which
> OpenSSH version 4 did not follow.)
Are you describing a change in sshd or in bash?
zsh does read .zshenv under current Debian's sshd.
> This makes stashing an svnserve
> alias or $PATH setting unavailable going forward, and dependent on the
> typically shared 'svn' user to have this set in their path for
> svn+ssh.
>
> ForceCommand looks like it will *break* ordinary svn+ssh, without
True. You could allow shell access if you took other steps to prevent
users from running 'cat' or (--log-file)-less 'svnserve' on the repository.
> using the SSH_ORIGINAL_COMMAND environment variable. Interesting. It
> would take fascinating parsing, and awkward configuration with managed
> SSH keys, but it's vaguely feasible.
>
> That looks...... really awkward to manage, and without any graceful
> SSH key management tools for Subversion access, it becomes a alocal
> and manually managed setup, and requires the manipulation of the SSH
> daemon's sshd_config. That's not very modular.
Replacing /usr/bin/svnserve by a 2-line wrapper script works too.
Received on 2011-04-02 06:53:21 CEST