[Bug 1346] PAM environment takes precedence over SendEnv

bugzilla-daemon at bugzilla.mindrot.org bugzilla-daemon at bugzilla.mindrot.org
Mon Jan 21 20:08:06 EST 2008


https://bugzilla.mindrot.org/show_bug.cgi?id=1346





--- Comment #2 from Jean-Christophe Dubacq <jcdubacq1 at free.fr>  2008-01-21 20:08:03 ---
A sysadmin, in a non-English speaking country, should set default
values (especially for locale related environment values). The natural
way to set these is through PAM (works across many shells). I also
implemented a no-clobber pam environment setting, but it will not work
for ssh AcceptEnv/SendEnv because (IIRC) the environment passed to pam
for initialisation is empty - it does not contain pre-set variables
with the ssh AcceptEnv/SendEnv variables set. This solution implies to
change 2 major components of a Unix system (openssh + PAM) instead of
only one (openssh). I also do not see how being conservative (putting
AcceptEnv on low priority) is helpful, especially in the case of
locales; if I remotely log into a japanese system, I want to be able to
type in French and read messages in French). The locales system
degrades correctly if the locale does not exist on the target system;
the user does not degrade correctly if the remote language is not
understood.

In short, I would like some kind of way to have remotely sent variables
override any defaults set by PAM. Maybe not all variables, but imagine
that for some users, having some incorrect LANG is the same as having
the wrong TERM variable (and TERM is dealt with specially in openssh).
Please consider that LC_CTYPE/LANG is as important as TERM as soon as
you are not in a pure ASCII language.

Of course, your position is somehow sensible if those were random
variable names. But the names for the locale-setting vars are fixed,
must be able to get defaults from pam, and must be overriden by the
user.

There is always the possibility of local hacks (AcceptEnv/SendEnv on
SSH_LANG, use the shell to copy LANG to SSH_LANG if it is not set and
from SSH_LANG to LANG if SSH_LANG is set, using the various level of
initialisation), but it is really cumbersome.

It is not also obvious why AcceptEnv/SendEnv should not get precedence.
After all, both sysadmins have to agree on which variables are
acceptable for import/export in the environment. The default on all
computers that I know of is "LANG LC_*". So if ssh cannot export LANG
LC_* as soon as there is some default set in PAM (and almost all
distributions do that), there is no use of this feature possible by
default. Of course, you are free to think that there should be no
default set by PAM, but think that in a non-English speaking
environment, something has to be done to put a default language (say,
French, Japanese or Latvian) for all "normal" users that use the
regular login (so that they can read their mails in the correct
encoding, almost all programs now read LANG or LC_CTYPE to know which
encoding to use).

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.


More information about the openssh-bugs mailing list