[arch-projects] [initscripts][RFC][PATCH] locale.sh: add support for user-specific locale.conf, drop DAEMON_LOCALE

[Sébastien Luttringer]

On Tue, Aug 28, 2012 at 4:59 PM, Dave Reisner <d at 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 at 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 at jklm.no> wrote:
>> >> > On Fri, Aug 24, 2012 at 7:02 PM, Dave Reisner <d at 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