Well, bad news. The /etc/security/pam_env.conf stuff is just as
useless as /etc/environment.
I tested two things. I placed the following two lines in the file:
FOO DEFAULT=${HOME}/bar
LANG DEFAULT=en_US.UTF-8
Then I did an "ssh localhost". The resulting login shell had the
variable FOO=/bar and it had the variable LANG=en_US.UTF-8 .
Next I did "LANG=lolcat ssh localhost". The resulting login shell
had the variable LANG=en_US.UTF-8 .
Then I removed the values from the file and logged in again with
"LANG=lolcat ssh localhost". The resulting shell had LANG=lolcat .
So:
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.
2) The variables set by ssh (LANG, etc.) CANNOT be given default values
here. Default values here become actual real forced values because
apparently the variables that are set by ssh aren't set yet when
pam_env.so runs.
Also noteworthy is the fact that the documentation for pam_env.conf is
more complete in the /etc/security/pam_env.conf file than in the man
page. The /etc/security/pam_env.conf file goes into much more detail
than the man page about the origins of the program and the issues and
caveats one should watch out for. It even mentions the issue with
variables like ${HOME} not being available yet, despite the fact that
it offers examples using precisely that.
Misleading, teasing examples.
(Seriously, what does pam_unix.so do? Apparently it does not set $HOME.
Because that's executed before pam_env.so and it talks about /etc/passwd
and so on, but ... does nothing? Joy.)
In conclusion, pam_env.so still can't do either of the two things I
actually care about (setting a variable with the user's $HOME or $LOGNAME
in it, or having a default fallback value for a variable like $LANG).
I'll continue setting variables in /etc/profile and so on, because that
actually friggin' WORKS. Mostly.
