On Fri, Mar 30, 2018 at 12:11:18PM -0700, Don Armstrong wrote:
> On Fri, 30 Mar 2018, Greg Wooledge wrote:
> > 1) ${HOME} is in fact NOT available to pam_env.conf at least for the
> > ssh "application" of PAM, despite being used in the documentation.
>
> That's why you need @{HOME}, not ${HOME}.
Same result.
$ tail -2 /etc/security/pam_env.conf
FOO DEFAULT=@{HOME}/bar
LANG DEFAULT=en_US.UTF-8 OVERRIDE=${LANG}
$ LANG=lolcat ssh localhost
[...]
$ env | grep -E '(FOO|LANG)='
LANG=en_US.UTF-8
FOO=/bar
> I think you want
>
> LANG DEFAULT=en_US.UTF-8 OVERRIDE=${LANG}
As far as I can tell, the LANG and LC_* variables are set by sshd itself
using values received through the network, from the client, after
PAM is all done. So, PAM is simply too early in the chain for this
to work. But this is all guesswork because there is apparently no
realistic way (short of source-diving) to figure out what each PAM
module actually DOES to the environment. Unless the answer is just
flat-out "They all do nothing", in which case my analysis is complete.
For this particular case, I think it *needs* to be done by a shell (or
by sshd itself), just because of the timing of everything. Unfortunate,
but understandable.
Still don't know why HOME can't work though. That one should be there.
> That's why you need @{HOME}, not ${HOME}.
WTF is a "PAM_ITEM"? pam_env.conf(5) refers to pam.d(5) and pam(7),
none of which defines what a PAM_ITEM is. Not that it really
matters since the answer is, once again, "This does nothing".
Neither one works.
