Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 168424 - environment variables are not set for non-interactive logins
Summary: environment variables are not set for non-interactive logins
Status: RESOLVED WORKSFORME
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] baselayout (show other bugs)
Hardware: All Linux
: High major with 1 vote (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-26 08:24 UTC by Jaco Kroon
Modified: 2009-05-15 06:13 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jaco Kroon 2007-02-26 08:24:02 UTC
jkroon@chimera ~ $ ssh root@tauri.local.uls.co.za echo '$PATH'
/usr/bin:/bin:/usr/sbin:/sbin
jkroon@chimera ~ $ ssh root@tauri.local.uls.co.za 
Last login: Mon Feb 26 10:09:56 2007 from 192.168.42.199
tauri # echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.1.1:/usr/i686-pc-linux-gnu/gcc-bin/4.1.1
tauri # 

This is caused by the exact same problem that was supposedly "fixed" in bug 26952, so please see my comments there on how to correctly fix both this issue, as well as that issue.

In the new bashrc files there are comments about scp and rsh, however, the comments neglect to take into consideration that there are apps like svnserve and friends for which one would like to configure a special umask before invoking the actual svnserve binary.

I also gave the example of running konqueror remotely via a non-interactive ssh shell in the other thread.  PATH should be set in bashrc, not in /etc/profile, as already explained in the other bug report.

The fix is simple, and I know the arguments has been thrown back and forth, and I'm aware that a lot of mud-slinging has happened with regards to this issue before, but I fear it's still not resolved.

Reproducible: Always
Comment 1 SpanKY gentoo-dev 2007-02-27 15:18:23 UTC
this is the correct behavior ... someone else reported this before but i cant find the bug report so i'll just mark this INVALID
Comment 2 Jaco Kroon 2007-02-27 16:11:29 UTC
I'll accept that when you can point me at documentation stating explicitly that that  is the correct behaviour.

To give but one counter example to what you're saying, when ssh'ing into a debian sarge boxen:

jkroon@pug ~ $ ssh jkroon@cluon.up.ac.za echo '$PATH'
/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin
jkroon@pug ~ $ 
Comment 3 Jaco Kroon 2008-06-01 12:11:56 UTC
bump
Comment 4 Peter Volkov (RETIRED) gentoo-dev 2008-06-02 10:28:30 UTC
Jaco, as I see in your last comments to bug #26952 I suppose that fixing PATH variable does not fix the whole problem which is that we don't get configured by system administrator environment for non-interactive logins. Thus why did you ask only about PATH in this bug? If system have libraries in non-default locations and configures their search path through env variables, setting PATH is not enough.

That said, setting environment in bashrc breaks ability to start terminal emulators in modified environment. See bug #26952 comment 2 item 1. I don't see any simple and clear way to fix this bug. Do you have any suggestions? How do other distributions handle this?

As a workaround for this problem you can currently use:
ssh user@server "bash --login -c command"
Comment 5 Jaco Kroon 2008-06-02 10:59:38 UTC
(In reply to comment #4)
> Jaco, as I see in your last comments to bug #26952 I suppose that fixing PATH
> variable does not fix the whole problem which is that we don't get configured
> by system administrator environment for non-interactive logins. Thus why did
> you ask only about PATH in this bug? If system have libraries in non-default
> locations and configures their search path through env variables, setting PATH
> is not enough.

Well, yes.  PATH is just the most prominent example.

> That said, setting environment in bashrc breaks ability to start terminal
> emulators in modified environment. See bug #26952 comment 2 item 1. I don't see
> any simple and clear way to fix this bug. Do you have any suggestions? How do
> other distributions handle this?

Debian handles this by sourcing /etc/bashrc from /etc/skel/.bashrc thus providing the user with control.

Additionally, the bash mechanism sources /etc/bashrc before ~/.bashrc afaik, thus again providing the user with override control.

Btw, I fully agree with the guy that filed bug #26952.

As the poster there points out, people are confusing the profile and rc files.  profile is used during _login_ (including xdm/gdm/kdm - kdm had a long standing bug where it bypassed using the users's login shell to spawn the login stuff but afaik that has been fixed).  rc is used to create the terminal environment if an user is already logged in.  So when /sbin/login (or one of the X variants) spawns the login shell then the profile stuff is run, when a terminal gets opened, the rc variants gets run.  _usually_.  In debian (at least) the default .bash_profile sources .bashrc so as to get those settings pulled in as well.

Thus the profile stuff is used _once_ during actual system login (unless it's a non-interactive login).  The rest of the time rc stuff is used.

Just to backup what I've said about sourcing .bashrc from .bash_profile I'll attach the /etc/profile, ~/.bashrc and ~/.bash_profile from a debian sid machine.  Debian is imho one of the distributions on which this works the best I've seen yet.

> As a workaround for this problem you can currently use:
> ssh user@server "bash --login -c command"

Ah thanks.  This helps but is again non-ideal.
Comment 6 Jaco Kroon 2008-06-02 11:44:53 UTC
Ok, I'm unable to create attachments atm, so I'll just get the highlights:

/etc/profile:

if [ "`id -u`" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games"
fi

if [ "$PS1" ]; then
  if [ "$BASH" ]; then
    PS1='\u@\h:\w\$ '
  else
    if [ "`id -u`" -eq 0 ]; then
      PS1='# '
    else
      PS1='$ '
    fi
  fi
fi

export PATH

umask 022

^^ These are the interactive login defaults.  ~/.bash_profile will get sourced directly after this:

# ~/.bash_profile: executed by bash(1) for login shells.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.

# the default umask is set in /etc/login.defs
#umask 022

# include .bashrc if it exists
if [ -f ~/.bashrc ]; then
    . ~/.bashrc
fi

# the rest of this file is commented out.

# set PATH so it includes user's private bin if it exists
#if [ -d ~/bin ] ; then
#    PATH=~/bin:"${PATH}"
#fi

# do the same with MANPATH
#if [ -d ~/man ]; then
#    MANPATH=~/man${MANPATH:-:}
#    export MANPATH
#fi

So it turns out they've got the _option_ of modifying PATH from here, and this file sources .bashrc:

# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything:
[ -z "$PS1" ] && return

# don't put duplicate lines in the history. See bash(1) for more options
#export HISTCONTROL=ignoredups

# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize

# enable color support of ls and also add handy aliases
if [ "$TERM" != "dumb" ]; then
    eval "`dircolors -b`"
    alias ls='ls --color=auto'
    #alias dir='ls --color=auto --format=vertical'
    #alias vdir='ls --color=auto --format=long'
fi

# some more ls aliases
#alias ll='ls -l'
#alias la='ls -A'
#alias l='ls -CF'

# set variable identifying the chroot you work in (used in the prompt below)
if [ -z "$debian_chroot" -a -r /etc/debian_chroot ]; then
    debian_chroot=$(cat /etc/debian_chroot)
fi

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
xterm-color)
    PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
    ;;
*)
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
    ;;
esac

# Comment in the above and uncomment this below for a color prompt
#PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '

# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
    PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}: ${PWD}\007"'
    ;;
*)
    ;;
esac

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profiles
# sources /etc/bash.bashrc).
#if [ -f /etc/bash_completion ]; then
#    . /etc/bash_completion
#fi

So yes.  It seems like I was wrong on how debian handles this nowadays.  The descriptions above are still useful though.  The debian system-wide /etc/bash.bashrc:

# System-wide .bashrc file for interactive bash(1) shells.

# To enable the settings / commands in this file for login shells as well,
# this file has to be sourced in /etc/profile.

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize

# set variable identifying the chroot you work in (used in the prompt below)
if [ -z "$debian_chroot" ] && [ -r /etc/debian_chroot ]; then
    debian_chroot=$(cat /etc/debian_chroot)
fi

# set a fancy prompt (non-color, overwrite the one in /etc/profile)
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '

# Commented out, don't overwrite xterm -T "title" -n "icontitle" by default.
# If this is an xterm set the title to user@host:dir
#case "$TERM" in
#xterm*|rxvt*)
#    PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}: ${PWD}\007"'
#    ;;
#*)
#    ;;
#esac

# enable bash completion in interactive shells
#if [ -f /etc/bash_completion ]; then
#    . /etc/bash_completion
#fi

It seems they're not following their own advice from /etc/bash.bashrc though, and /etc/profile is in fact _not_ sourcing the file.

Ok, in spite of this I'd still like to point out the following:

profile => interactive login shells.
rc => non-interactive login shells, or sub-shells.

So the question really should become where is the appropriate place to put what.

And here I'm probably fighting a battle on my own, but I honestly don't think the current way is the best way.  My personal opinion (and others may agree or disagree) is that there is a lot of checks going into the rc files to prevent certain things from happening (as witnessed by the checks for interactive shells).  These checks (imho) are superfluous in most cases as the stuff it's protecting belongs in the profile variant.  We need to distinguish what needs to get set when, and under which circumstances, so the problematic stuff is PATH and friends.

In my opinion PATH (and friends, hereon after simply referred to as PATH) needs to be set on _all_ login shells at the very least, but imho setting the PATH when a shell starts up is fine.  bash can be invoked with --norc if a person does not want this, or even --rcfile if an alternate bashrc file is required.

I quote the bash man page:

--norc Do not read and execute the personal initialization file ~/.bashrc if the shell is interactive.  This option is on by default if the shell is  invoked  as sh. 

--noprofile Do  not  read  either the system-wide startup file /etc/profile or any of the personal initialization files ~/.bash_profile, ~/.bash_login, or ~/.profile. By default, bash reads these files when it is invoked as a login shell (see INVOCATION below).

--rcfile file Execute commands from file instead of the standard personal initialization file ~/.bashrc if the shell is interactive (see INVOCATION below).

Those descriptions also gives a relatively clear indication of when what gets sourced by default, but does not cover all cases:

login     interactive     sourced files
  Y           Y             profile
  Y           N             bashrc
  N           Y             bashrc
  N           N             _nothing_

Ok.  So the authors of bash was pretty thorough, and those descriptions above are reasonably accurate.  Note that in the interactive login case .bashrc is sourced via .bash_profile.

In all the cases above imho where bashrc is processed we DO want to set PATH and friends.  bashrc is also the appropriate place to set a bash specific PS1 imho.

If there is wider interest I'd be willing to cook up some profile and rc files for wider testing (ie, unhack the ones I use and "generalize" them a little so that they're more widely usable).  I'm just insanely busy with business related work at the moment (need to put food on my own and other people's tables), so this may well take a month to get to.

It's been a long post, I'm crazy tired, I sincerely hope the above is coherent.
Comment 7 Peter Volkov (RETIRED) gentoo-dev 2008-06-02 15:41:27 UTC
(In reply to comment #6)
> It seems they're not following their own advice from /etc/bash.bashrc though,
> and /etc/profile is in fact _not_ sourcing the file.

Well I've checked current (from unstable I suppose) debian /etc/profile and they
do source /etc/bash.bashrc there.

> login     interactive     sourced files
>   Y           Y             profile
>   Y           N             bashrc
>   N           Y             bashrc
>   N           N             _nothing_

No, in case of login shell profile files are sourced in any case. From man
page:

When Bash is invoked as an interactive login shell, or as a non-interactive
shell with the `--login' option, it first reads and executes commands from the
file `/etc/profile', if that file exists.  After reading that file, it looks
for `~/.bash_profile', `~/.bash_login', and `~/.profile', in that order, and
reads and executes commands from the first one that exists and is readable.

> In all the cases above imho where bashrc is processed we DO want to set PATH
> and friends.  bashrc is also the appropriate place to set a bash specific PS1
> imho.

You missed my point. If you'll set PATH in bashrc then any attempts to start
xterm/aterm with modified path fail. I mean if you'll do:

$ export PATH=/my/best/path
$ xterm

you'll get system default PATH again inside xterm as it'll be overridden by
.bashrc. And no, forcing users to run "bash --norc" is nothing better then,
already suggested workaround "bash --login".


Now, I'm also closing this bug as WORKSFORME, and here's why:

1. The files you listed here and the one I've downloaded from Debian site
reveiled that Debian does not sets PATH in neither /etc/bash.bashrc nor
~/.bashrc.

2. I suppose the PATH you see during non-interactive login in Debian is the
default PATH set by sshd server. In openssh this value could be configured
with --with-default-path= or --with-superuser-path= configure switches.  I
suppose in Debian this is tweaked to the values you see while in Gentoo it's
kept with sane default suggested by upstream and nobody should change that. In
Gentoo if you need to tweak this value you can run install openssh with the
following command:

EXTRA_ECONF='--with-default-path=/usr/bin:/bin:/whatever/path/you/want' emerge -1va openssh

If you want to have this value always set for openssh builds run the following
commands:

# mkdir /etc/portage/env/net-misc
echo "EXTRA_ECONF='--with-default-path=/usr/bin:/bin:/whatever/path/you/want'"
>> /etc/portage/env/net-misc/openssh

man portage for further details about /etc/portage/env.

You are free to reopen if you disagree but then provide us with more ideas.
Exact exact code sniplets from Debian system on where and how they set
PATH in bashrc and how the don't check for interactivity (note [ -z "$PS1" ] checks at the beginning of all bashrc files).

Well currently I don't see how to achieve what you want in trough bashrc but obviously this possible to archive by other means :)
Comment 8 Jaco Kroon 2008-06-02 18:02:21 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > It seems they're not following their own advice from /etc/bash.bashrc though,
> > and /etc/profile is in fact _not_ sourcing the file.
> 
> Well I've checked current (from unstable I suppose) debian /etc/profile and
> they
> do source /etc/bash.bashrc there.
> 
> > login     interactive     sourced files
> >   Y           Y             profile
> >   Y           N             bashrc
> >   N           Y             bashrc
> >   N           N             _nothing_
> 
> No, in case of login shell profile files are sourced in any case. From man
> page:

The above is from observed behaviour.  I added "echo" lines to the .bash_profile and .bashrc files and checked what actually gets sourced.  For interactive login I simply ssh'ed into the box.  For login, non-interactive I supplied ssh with a command to execute immediately.  For non-login, interactive I simply issued /bin/bash from an existing shell, for non-login, non-interactive I issued /bin/bash -c /bin/false.

This behavious is in line with that described by the --norc and --noprofile options as quoted earlier.

> When Bash is invoked as an interactive login shell, or as a non-interactive
> shell with the `--login' option, it first reads and executes commands from the
> file `/etc/profile', if that file exists.  After reading that file, it looks
> for `~/.bash_profile', `~/.bash_login', and `~/.profile', in that order, and
> reads and executes commands from the first one that exists and is readable.

Please note "non-interactive _with_ the --login" option.  A login shell, is afaik, identified generally by looking for a - as the first char of argv[0].  Unless ssh doesn't spawn a login shell when it's non-interactive.  Something which i can't confirm (easily) since "ssh jkroon@myserver ps axf" doesn't show the bash process any more:

13250 ?        S      0:00      \_ sshd: jkroon@notty
13251 ?        Rs     0:00          \_ ps axf

The interactive login case via ssh:

12512 ?        S      0:00      \_ sshd: jkroon@pts/0
12513 pts/0    Ss     0:00          \_ -bash


> > In all the cases above imho where bashrc is processed we DO want to set PATH
> > and friends.  bashrc is also the appropriate place to set a bash specific PS1
> > imho.
> 
> You missed my point. If you'll set PATH in bashrc then any attempts to start
> xterm/aterm with modified path fail. I mean if you'll do:
> 
> $ export PATH=/my/best/path
> $ xterm

Youch, this is a sticky one indeed.  And yes, I missed that one.  Would you be so kind as to supply an example of why this would be useful?  I'm pretty sure it can be, I just don't see how (yet).

> you'll get system default PATH again inside xterm as it'll be overridden by
> .bashrc. And no, forcing users to run "bash --norc" is nothing better then,
> already suggested workaround "bash --login".

Understood.  I'd like to point out, however, that the I've never (before) seen a case where I actually (personally) don't want to have the PATH (re)set.  I have, however, seen many examples where I do want the path set for non-interactive shells (the one I consistently bump into):

cat >/usr/local/bin/svnserve <<FOO
#! /bin/bash

umask 002
exec /usr/bin/svnserve "$@"
FOO
chmod 755 /usr/local/bin/svnserve

and then:

svn co svn+ssh://user@server/path/to/repo

I don't exactly see a clean way of handling that, even with --login.

> Now, I'm also closing this bug as WORKSFORME, and here's why:
> 
> 1. The files you listed here and the one I've downloaded from Debian site
> reveiled that Debian does not sets PATH in neither /etc/bash.bashrc nor
> ~/.bashrc.

Fine.  I can take that.  I'm pretty sure I've got it right as to PATH having been set from rc at some point in the past.  I may just be old-fashioned but that approach still worked better for me (if I recall correctly, of course ... I don't have debian potato lying around any more though).  Haven't seriously used debian since potato so looks like things changed.  I'm not sure whether it's for the better yet.

> 2. I suppose the PATH you see during non-interactive login in Debian is the
> default PATH set by sshd server. In openssh this value could be configured
> with --with-default-path= or --with-superuser-path= configure switches.  I
> suppose in Debian this is tweaked to the values you see while in Gentoo it's
> kept with sane default suggested by upstream and nobody should change that. In
> Gentoo if you need to tweak this value you can run install openssh with the
> following command:

$ strings /usr/sbin/sshd  | grep usr
...
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11
/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
...

$ grep PATH /etc/profile
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11"
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games"
export PATH

$ ssh jkroon@debianserver 'echo $PATH' 
/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games

Could be either one of the two from /etc/profile or from the default sshd path.  Modifying /etc/profile reveals that it is in fact from sshd.

The above does however show that Debian uses a considerably more sane default PATH variable.  Take for example:

$ ssh jkroon@xacatecas.lan 'echo $PATH'
/usr/bin:/bin:/usr/sbin:/sbin

What is */sbin doing in a non-root user's default PATH?!?

> EXTRA_ECONF='--with-default-path=/usr/bin:/bin:/whatever/path/you/want' emerge
> -1va openssh
> 
> If you want to have this value always set for openssh builds run the following
> commands:
> 
> # mkdir /etc/portage/env/net-misc
> echo "EXTRA_ECONF='--with-default-path=/usr/bin:/bin:/whatever/path/you/want'"
> >> /etc/portage/env/net-misc/openssh

A great, been wondering about that one.

> man portage for further details about /etc/portage/env.
> 
> You are free to reopen if you disagree but then provide us with more ideas.
> Exact exact code sniplets from Debian system on where and how they set
> PATH in bashrc and how the don't check for interactivity (note [ -z "$PS1" ]
> checks at the beginning of all bashrc files).

I'll need to sleep on this.  You are probably the first person pointing out some sane arguments on this and not simply telling me to bugger off.  Thanks for that.

> Well currently I don't see how to achieve what you want in trough bashrc but
> obviously this possible to archive by other means :)

The only thing I can see that is problematic with my way is the one single solitary example you pointed out.  There are probably others too, but I'm unable to think of any (Or I'm just too hard-headed to accept that I might be wrong).

Regards,
Jaco
Comment 9 Peter Volkov (RETIRED) gentoo-dev 2008-06-04 14:32:06 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > login     interactive     sourced files
> > >   Y           Y             profile
> > >   Y           N             bashrc
> > >   N           Y             bashrc
> > >   N           N             _nothing_
> > 
> > No, in case of login shell profile files are sourced in any case. From man
> > page:
> 
> The above is from observed behaviour.  I added "echo" lines to the
> .bash_profile and .bashrc files and checked what actually gets sourced.  For
> interactive login I simply ssh'ed into the box.  For login, non-interactive I
> supplied ssh with a command to execute immediately.  For non-login, interactive
> I simply issued /bin/bash from an existing shell, for non-login,
> non-interactive I issued /bin/bash -c /bin/false.

And this means that whenever you call "ssh user@server command" you don't have
login shell. If you need non-interactive login shell you should explicitly
call bash with --login option.

> > When Bash is invoked as an interactive login shell, or as a non-interactive
> > shell with the `--login' option, it first reads and executes commands from the
> > file `/etc/profile', if that file exists.  After reading that file, it looks
> > for `~/.bash_profile', `~/.bash_login', and `~/.profile', in that order, and
> > reads and executes commands from the first one that exists and is readable.
> 
> Please note "non-interactive _with_ the --login" option.  A login shell, is
> afaik, identified generally by looking for a - as the first char of argv[0]. 

Use shopt to check for login shell or "shopt -p login_shell".

> Unless ssh doesn't spawn a login shell when it's non-interactive. 

And this is the case.

> > > In all the cases above imho where bashrc is processed we DO want to set PATH
> > > and friends.  bashrc is also the appropriate place to set a bash specific PS1
> > > imho.
> > 
> > You missed my point. If you'll set PATH in bashrc then any attempts to start
> > xterm/aterm with modified path fail. I mean if you'll do:
> > 
> > $ export PATH=/my/best/path
> > $ xterm
> 
> Youch, this is a sticky one indeed.  And yes, I missed that one.  Would you be
> so kind as to supply an example of why this would be useful?  I'm pretty sure
> it can be, I just don't see how (yet).

Well. Actually I don't use this behaviour. That's just what other users rely
on... Again, take a look at bug #26952 comment 2 item 1.
 
> > you'll get system default PATH again inside xterm as it'll be overridden by
> > .bashrc. And no, forcing users to run "bash --norc" is nothing better then,
> > already suggested workaround "bash --login".
> 
> Understood.  I'd like to point out, however, that the I've never (before) seen
> a case where I actually (personally) don't want to have the PATH (re)set.  I
> have, however, seen many examples where I do want the path set for
> non-interactive shells (the one I consistently bump into):
> 
> cat >/usr/local/bin/svnserve <<FOO
> #! /bin/bash
> 
> umask 002
> exec /usr/bin/svnserve "$@"
> FOO
> chmod 755 /usr/local/bin/svnserve
> 
> and then:
> 
> svn co svn+ssh://user@server/path/to/repo

Well, I'm not sure this is right way to handle such situations as you have two
svnserve binaries in PATH and you should be twice sure that you call correct
one... Very fragile IMO. May be you should concider different approaches, but
I can't suggest best solution here. You'd better ask svn mailing list. May be
there is way to check that that's svn+ssh connecting... But one possible
solution which somes to my mind is that you could start sshd for svn on
different port and then in bashrc you could parse SSH_CONNECTION environment
variable for port on which ssh client was connecting. And if port is different
from 22 change umask. At the same time on client side you could configure
tunnel to simplify access:

http://svnbook.red-bean.com/en/1.0/ch06s03.html
 
> I don't exactly see a clean way of handling that, even with --login.

Me too. But note that similar script in svn book references 
/usr/local/subversion/bin/svn binary which is not in PATH. While in your
example both svnserve binary and script are in PATH.

> > 2. I suppose the PATH you see during non-interactive login in Debian is the
> > default PATH set by sshd server. In openssh this value could be configured
> > with --with-default-path= or --with-superuser-path= configure switches.  I
> > suppose in Debian this is tweaked to the values you see while in Gentoo it's
> > kept with sane default suggested by upstream and nobody should change that. In
> > Gentoo if you need to tweak this value you can run install openssh with the
> > following command:
> 
> $ strings /usr/sbin/sshd  | grep usr
> ...
> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11
> /usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
> ...
> 
> $ grep PATH /etc/profile
>  
> PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11"
>   PATH="/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games"
> export PATH
> 
> $ ssh jkroon@debianserver 'echo $PATH' 
> /usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
> 
> Could be either one of the two from /etc/profile or from the default sshd path.
>  Modifying /etc/profile reveals that it is in fact from sshd.
> 
> The above does however show that Debian uses a considerably more sane default
> PATH variable.  Take for example:
> 
> $ ssh jkroon@xacatecas.lan 'echo $PATH'
> /usr/bin:/bin:/usr/sbin:/sbin
> 
> What is */sbin doing in a non-root user's default PATH?!?

Could be. But Gentoo policy is to follow as close to upstream as possible. If
you want to change this default you should speak with upstream, or modify this
locally ;)
 
Comment 10 J.R. Mauro 2009-05-15 06:13:10 UTC
This really should be reopened. SSH developers should not be dictating what my PATH should be for non-interactive non-login shells, especially when it prevents me from running things without full paths/other kludges. The ability to set the path should be dynamic or configurable. Statically compiling /bin:/usr/bin:/sbin:/usr/sbin as the PATH is ridiculous.