On Fri, Aug 31, 2012 at 4:17 PM, Sébastien Luttringer <seblu@seblu.net> wrote:
On Tue, Aug 28, 2012 at 4:59 PM, Dave Reisner <d@falconindy.com> wrote:
On Tue, Aug 28, 2012 at 04:50:44PM +0200, Sébastien Luttringer wrote:
On Tue, Aug 28, 2012 at 4:40 PM, Dave Reisner <d@falconindy.com> wrote:
On Tue, Aug 28, 2012 at 04:31:09PM +0200, Sébastien Luttringer wrote:
On Fri, Aug 24, 2012 at 7:44 PM, Tom Gundersen <teg@jklm.no> wrote:
On Fri, Aug 24, 2012 at 7:02 PM, Dave Reisner <d@falconindy.com> wrote: > Still, I guess my point is that we should be testing for the presence of > variables before trying to expand them. from pam_env.conf manual: The /etc/security/pam_env.conf file specifies the environment variables to be set, unset or modified by pam_env(8)
Nothing about the text that follows in the manpage describes how to _limit_ the variables that can be set in the environment file. It only describes defaults and overrides. I've perused the code as well. I have yet to find this fabled whitelist. ok I was a bit enthusiastic reading the man page. My bad.
But why would we filter variables defined in /etc/environment? After all, LANG and LC_* are environment variables why would they have the privilege of having a separate configuration file?
Looking into debian pam settings, I read this. # locale variables are also kept into /etc/default/locale in etch # reading this file *in addition to /etc/environment* does not hurt session required pam_env.so readenv=1 envfile=/etc/default/locale They use pam_env to load locale. -- Sébastien "Seblu" Luttringer www.seblu.net