Re: *term -ls, a summary

[Isaac To <kkto@csis.hku.hk>]

>>>>> "Norbert" == Norbert Veber <nveber@debian.org> writes:

Sorry that I reply late.  I really started to wonder whether anybody is
reading the discussion.

    Norbert> I really cant imagine why you would not want to be able to set
    Norbert> the environment.  Of course ssh has the .environment file,
    Norbert> thogh that wasnt always there either.  However what the real
    Norbert> point is that ssh has just about as much of a right to set my
    Norbert> environment as say xterm does.  That is to say that ssh
    Norbert> shouldnt do it just as xterm doesnt..

As I've said, ssh and xterm are *different*.  If you run xterm, it is your
own process which fork out the new process to run xterm.  So it has no
business to work on the environment which is already setup.  On the other
hand, ssh does not fork out a new shell.  Instead, ssh contacts the
remote-end sshd program, does authentication, and then have the *remote-end*
sshd fork out a shell.  So I don't fork() out a program myself.  The remote
sshd does that for me.  Since sshd does not run in my environment, it *must*
take the responsibility to set it up before running my commands.

It is *not* a special case: every program forked off from a system service,
or suid into another user running arbitrary commands from there, should be
treated *the same*.  So there are two groups of programs, one consisting of
things like xterm, emacs, vi, etc., which executes within a pre-defined
environment and thus should not create login shell on its own by default;
and the other group consisting of things like login, sshd, ftpd, cron, atd,
su, etc. which /should/ always create a user environment.

The dispute comes from the fact that there are two ways to create a user
environment.  Either you run a login shell in the new process, or (for ssh)
you read the .ssh/environment file in the new process.  Indeed, the latter
is not a complete solution: it allows you to setup environment variables,
but nothing else (Ulimits?  Current directory?  Umask?  Signal handling?
Nice level?  Wow... the environment variables are such a big deal...).

But there are two other problems with this approach.  First, if ssh decides
to get its environment from .ssh/environment, why should it creates a login
shell when I login interactively?  The environment is already setup by
.ssh/environment, so now it is no different from xterm: it runs in an
environment which is already set for running.  Either you always use
.ssh/environment, or you always use a login shell.  Doing both means that
you lose your guarantee that you initialize everything exactly once.

There is another problem: management.  Currently if I want to modify an
initial environment variable, I have to modify two files: .xsession, and
.profile.  Luckily I no longer use tcsh, otherwise I've to modify .login as
well.  And, I source .profile from .xsession, so everything is in .profile.
It is never a good experience to need editing many file for one change.  But
.ssh/environment basically necessitate that, since .ssh/environment does not
follow shell syntax, but instead follow a trimmed down /etc/environment
syntax.  You just can't simply source the .ssh/environment file from your
.profile.  And of course having an environment files specific to ssh which
is inspected before the normal .profile file is plain stupid: if I want
special things for ssh sessions, I'm not going to want it overwritten by the
settings in .profile.

BTW, it is easy to fix the behaviour.  E.g., in ssh, we can fix the problem
by, e.g., changing line 1407 of session.c from

        argv[0] = (char *) shell0;

to

        argv[0] = "-";

(and a few more places, e.g., in sftp.c.)

And in cron, one can fix the problem by changing just one line (line 301) of
do_command.c from

                    execle(shell, shell, "-c", e->cmd, (char *)0, e->envp);

to

                    execle(shell, "-", "-c", e->cmd, (char *)0, e->envp);

Why the Debian community want everybody who want a sane environment to do
this locally in their own computer is something I've got no clue about.

One last thing: if you didn't tag the bug as "important", the maintainer
probably had more time thinking about the problem before marking it as done.

Regards,
Isaac.