Re: Bug#790401: openssh: Please pass the XTERM_VERSION environment variable
On 2015-06-30 16:32:53 +0200, Christoph Anton Mitterer wrote:
> On Tue, 2015-06-30 at 13:30 +0200, Vincent Lefevre wrote:
> > This is not completely true: this is the case *by default*, but the
> > user can always change the default. When I get an account on a
> > machine,
> > one of the first things I do is to install terminfo files in my home
> > directory, so then I always have the same ones on all machines.
> Which is a nice solution, but I fail to see how any of this justifies
> that we send/accept even more env vars that may cause troubles.
Sending TERM is absolutely necessary because different terminals
behave in different ways.
> What keeps you from also just setting your LC_*, XTERM_* and so on in
> your remote user's .profile/.bashrc/etc. *if* your sysadmins are so
> uncooperative not to add them to the accept list?
Because their values depend on the client side.
> Hehe,... I had similar arguments when I reported this upstream (IIRC at
> the Debian level my bug report was simply ignored)... but they brought
> up some obsucre reasons why VTE/Gnome Terminal is amongst the few
> emulators where it's simply necessary that they fake xterm.
>
> Perhaps you can try to convince them to behave nicely :)
I doubt I can. I had similar problems with the iTerm developer, who
didn't want to have its own TERM value. The TERM value was configurable,
but with very few possible choices, and I had to use xterm-color, with
a modified terminfo specifically for iTerm.
> > > Doesn't it also potentially affect the output/behaviour of
> > > programs?
> >
> > It allows to get the same output as characters. For instance, if
> > the charmap is passed correctly, "env LANG=fr_FR cp" will always
> > output something like:
> >
> > cp: opérande de fichier manquant
> > Saisissez « cp --help » pour plus d'informations.
> >
> > Otherwise one can get garbage in the terminal.
>
> Well but you'd only get the same output:
> a) on terminals
> b) when these have the correct charmap set.
For (b), this is exactly the reason why I need to transmit the charmap.
> If for some reasons the output goes into a file, which can happen, then
> the binary representation would be different, wouldn't it?
The solution is to set the locales in the script (or in some shell
rc file). That way, it will still work even if the admin chooses to
change the default locales.
> > With Debian, the default is not
> > to have restricted user environments: when SSH is installed, any
> > local end user can log in via SSH. So, it makes sense to have a
> > default AcceptEnv following this.
> Then you could again argue to that we simply Accept/Send *, including
> e.g. LD_LIBRARY_PATH.
It makes no sense to send/accept LD_LIBRARY_PATH because the paths
are typically different on the remote system. So, it will more
likely break things than solve things... possibly even before the
user can correct the value.
> > In any case, if you think that there is any risk with SSHENV_FOO,
> > then there is also a risk for SSH_ORIGINAL_COMMAND.
> >
> > Anyway, if some program wants to use SSHENV_FOO or
> > SSH_ORIGINAL_COMMAND
> > for its own use, it should unset it first. This is good programming
> > practice.
> So since one cannot know in advance which names may ever be used by
> some other application, one would basically need to unset everything
> (except those names for which one knows that one definitely uses them
> securely, regardless of their content), right?
No. An application should not use a prefix that is already used,
in particular from well-known tools such as SSH. So, using a SSH
prefix is definitely a wrong idea.
Following your thoughts, what if you have two different applications
using the same environment variable for different purpose? This could
also yield privacy/security problems.
> Then we're basically back to having this job done safely by e.g. ssh
> (which it does per default).
>
> And as I've said before,... expecting that every program can/would do
> such proper cleanup is simply naive -
Every sensitive program should do so because of possible clashes
between them.
> which is again just the reason why we don't place this
> responsibility not into e.g. each and every CGI script but into
> Apache.
In a similar way, the shell (or command) started by sshd could do
that. Then this shell or special command would execute the real
program.
> > > > BTW, a ssh server can have several users, with different needs:
> > > > some will need some environment variable passing, others won't
> > > > need that and can always clean up the environment before doing
> > > > anything else (say, start with "env -i" or do something similar).
> > >
> > > Which can be easily facilitated by a number of technologies in
> > > OpenSSH:
> > > - environment="NAME=value" in authorized_keys
> > > - PermitUserEnvironment in sshd_config
> > > (notice again, that the default to this directive is of course
> > > "no"
> > > for security reasons - just as with Send/AcceptEnv)
> > > - Match/Host blocks that select config directive based on the
> > > User/Host
> > > in ssh[d]_config
> >
> > ???
>
> You said that some users would need env var passing some not.
Yes, and the only solution I see, and the one recommended by upstream,
is to use SendEnv/AcceptEnv. The other users can easily clean up the
environment with "env -i". But really, this wouldn't even be needed
with SSHENV_* variables, and in practical cases, applications can
just ignore the additional variables (FYI, though transmitted, the
standard LC_* variables are reset by PAM before the user can see the
transmitted values).
> Instead I showed you some ways where you could selectively configure
> the send/accepted environment based on the authenticating user, the
> user logged in to, and so on... by which one wouldn't need to possibly
> disturb everyone else.
You didn't show anything.
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Reply to: