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? mkinipcio/systemd can look into /etc/environment instead of /etc/locale.conf. I'm wondering why systemd don't do this. Any thought?
You could put anything you want in here. Where the magic begin. If all requirement are met, we can drop all profile.d crap.
Lots of profile.d scripts contain conditional logic. Whether or not this is right, there is no substitute for it in pam_env.
That's an issue. I found more interesting to fix this in pam_env rather than to lug shell scripts to source variables without conditions. -- Sébastien "Seblu" Luttringer www.seblu.net