On Tue, 2015-06-30 at 17:26 +0200, Vincent Lefevre wrote: > Sending TERM is absolutely necessary because different terminals > behave in different ways. And that's why SSH sends it... others are not important, thus, they don't sent by default. > > 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. But then you contol both, client and server side. Just manually set it to the same, and bon. > > 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. Yeah,.. the whole situation in that field is quite unfortunate... :( > > > > 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. Well but this is simply not how things are generally handled. The locale is set system wide and/or by the users. Some DEs (perhaps GNOME? ;-) ) perhaps override that with their own settings but that would already be bad as it breaks long standing behaviour. If you go remotely than apps running there should at first run with the remote settings (i.e. locale/etc.) and if this is not desired as in your case it should be your manual duty to adapt/change the settings... and not the duty of everyone else to adapt to your wishes. > > > 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. This is absolutely not necessarily the case.... you could simply have the same distribution or whole software bundles that reside in /opt /afs or wherever, the later is for example typical here in the LHC Comuting Grid,... the whole software tree used by the experiments (including compilers, etc.) is in one standardised tree, identical amongst all possible distros. > 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. Don't you just get it or are you simply keep ignoring it? There is no registry or standard who defines what's well known and what's not. I thought the Lumia example would have quite nicely explained it. You can just place responsibility on everyone else to know the names which *you* or *I* think are to be considered well known. > 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. Which is the case. But of course *only* if such programs somehow inherit their own environment to other programs (e.g. via execv).... and this is the case for SSH. If the invoked program (i.e. programs you run via ssh, like ls, ps and so on) is not specifically intended as always being invoked from a potentially hostile environment, than the responsibility to clean the same up is definitely upon the invoker (in that case, ssh). Even for programs that could expect a hostile environment (e.g. CGI scripts) we typically handle the clean up at the invoker level. That's just how most such systems that I'd know off handle things by default. > > 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. Sure, it could. But the shell is just the shell, and not necessarily a program designed to be executed from remote,... that's what SSH is designed for,... and since the potential insecurity comes from the remote environment it's naturally the responsibility of SSH to clean it up, not of the shell. > 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". To be hones, this discussion is getting moot... and apparently you're twisting up words here. Upstream does explicitly *not* recommend to send/accept any env vars *by default* which would affect any users, they even warn about it, which I told you already before. And in all doing respect, your insistence that all others should clean up all their stuff because of your personal wishes, seems a bit arrogant. > But really, this wouldn't even be needed > with SSHENV_* variables, and in practical cases, applications can > just ignore the additional variables As I said before, I still have concerns about this,... but it's something you should probably discuss upstream. But as I've said before, I doubt they will auto send/accept all envvars from the client into their "SSHENV_" counterparts. And one should probably call it SSH_ENV_ so that it matches the already used style of OpenSSH's env vars. > (FYI, though transmitted, the > standard LC_* variables are reset by PAM before the user can see the > transmitted values). If PAM is used (see the UsePAM directive)...
Attachment:
smime.p7s
Description: S/MIME cryptographic signature