Re: Ideal place to set environment variables

[David Wright]

On Mon 09 Apr 2018 at 08:32:00 (-0400), Greg Wooledge wrote:
> On Sat, Apr 07, 2018 at 11:47:19AM +0100, Jonathan de Boyne Pollard wrote:

… a post that doesn't seem to have made it to the archives.
https://lists.debian.org/debian-user/2018/04/author.html

> > 
> >   
> 
> Really? :-(
> 
> > 
> > 
> > The $ metacharacter is documented in the FreeBSD
> >   manual page that I pointed to before, alongside a ~
> >   metacharacter which yields your desired result fairly trivially. 
> 
> OK.  I confess I only looked at the "setenv" section which says "A
> comma-separated list of environment variables and values to which they
> are to be set."  Then jumped to the bottom to look for examples, of
> which there are zero.
> 
> I guess I should have read every single sentence, to find the part
> about `~' and `$'.  That looks sufficient for all the real-world
> cases I've seen.

Looks to me like a bug in the man page. That paragraph doesn't
belong under "Authentication".
https://www.freebsd.org/cgi/man.cgi?query=login.conf

Cheers,
David.

Re: Ideal place to set environment variables

[Greg Wooledge]

On Sat, Apr 07, 2018 at 11:47:19AM +0100, Jonathan de Boyne Pollard wrote:
> 
>   

Really? :-(

> 
> 
> The $ metacharacter is documented in the FreeBSD
>   manual page that I pointed to before, alongside a ~
>   metacharacter which yields your desired result fairly trivially. 

OK.  I confess I only looked at the "setenv" section which says "A
comma-separated list of environment variables and values to which they
are to be set."  Then jumped to the bottom to look for examples, of
which there are zero.

I guess I should have read every single sentence, to find the part
about `~' and `$'.  That looks sufficient for all the real-world
cases I've seen.

Re: Ideal place to set environment variables

[Greg Wooledge]

On Fri, Mar 30, 2018 at 12:57:23PM -0700, Don Armstrong wrote:
> See 
> https://github.com/linux-pam/linux-pam/blob/master/modules/pam_env/pam_env.c#L668

Oh, look, a pam_syslog call.  I didn't think to check logs.

Mar 30 15:45:01 wooledg CRON[28166]: pam_env(cron:session): Unknown PAM_ITEM: 

Mar 30 15:45:01 wooledg CRON[28166]: pam_env(cron:session): Unknown PAM_ITEM: 

Re: Ideal place to set environment variables

[Don Armstrong]

On Fri, 30 Mar 2018, Greg Wooledge wrote:
> On Fri, Mar 30, 2018 at 12:11:18PM -0700, Don Armstrong wrote:
> > 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

Hrm; this feature was added around 1.2.1, and we're still using 1.1.8.[1]


> there is apparently no realistic way (short of source-diving) to
> figure out what each PAM module actually DOES to the environment.

In pam_env, there's a debug option.

> WTF is a "PAM_ITEM"? pam_env.conf(5) refers to pam.d(5) and pam(7),

See 
https://github.com/linux-pam/linux-pam/blob/master/modules/pam_env/pam_env.c#L668

1: https://bugs.debian.org/821408
-- 
Don Armstrong  https://www.donarmstrong.com

"She decided what she wished to happen and then assumed that reality
would bend to her wishes." [...] "Reality doesn't indulge wishes."
 -- Terry Goodkind _Phantom_ p133

Re: Ideal place to set environment variables

[Greg Wooledge]

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
LANGDEFAULT=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.

Re: Ideal place to set environment variables

[Don Armstrong]

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}.

[...]

> 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

That's @{HOME}

> $LOGNAME in it,

That's @{PAM_USER}.

> or having a default fallback value for a variable like $LANG).

I think you want

LANG DEFAULT=en_US.UTF-8 OVERRIDE=${LANG}

-- 
Don Armstrong  https://www.donarmstrong.com

Il semble que la perfection soit atteinte non quand il n'y a plus rien
a ajouter, mais quand il n'y a plus rien a retrancher.
(Perfection is apparently not achieved when nothing more can be added,
but when nothing else can be removed.)
 -- Antoine de Saint-Exupe'ry, Terres des Hommes

Re: Ideal place to set environment variables

[Glenn English]

My domain is slsware.*, and I run bash.

Therefore I created /etc/sls/ and wrote a little script in that
directory called slswaredefs.sh and sourced it near the bottom of
everybody's .bashrc.

For more/other shells, write in Perl/Python and switch on shell in the
list of of environment variables going into the login file (haven't
tried that). Or maybe write a bunch of little scripts in the shell's
script language for different shells.

Works good, so far...

-- 
Glenn English

Re: Ideal place to set environment variables

[Greg Wooledge]

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
LANGDEFAULT=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.

Re: Ideal place to set environment variables

[Greg Wooledge]

On Fri, Mar 30, 2018 at 10:09:48AM -0700, Don Armstrong wrote:
> On Fri, 30 Mar 2018, Greg Wooledge wrote:
> > I have an extremely simple real-world litmus test which every system
> > I've ever seen so far has failed:
> > 
> >   How do I set MAIL=$HOME/Maildir/ in the login environment of every
> >   user, regardless of their shell, or how they log in (console, ssh,
> >   X Display Manager, GNOME Display Manager, etc.)?
> > 
> > That's it.  Simple, right?  But login.conf can't do it.  And pam_env.so
> > can't do it.  They only allow static strings with no substitutions.
> 
> pam_env.so can do substitutions, like:
> 
> MAIL DEFAULT=${HOME}/Maildir
> 
> Though that assumes that HOME was actually set (probably not) at the
> time that pam_env fires.

OK.  Interesting.  Either this stuff was added after I had already given
up on it (many years ago), or I simply failed to find it back then.

The syntax Don is showing here is *NOT* usable in /etc/environment
but rather in a totally separate file called /etc/security/pam_env.conf
which is documented in "man pam_env.conf" (not in "man pam_env").

/etc/environment continues to be as useless as ever.

P.S. pam_env.conf(5) shows examples using ${HOME} so one would assume
that $HOME is available at that point.  I haven't tested yet.

> In this case, you likely really want pam_mail, and something like:
> 
> session optional pam_mail.so dir=~/Maildir nopen

... so, someone was so frustrated by pam_env not being useful that
they wrote an entire separate PAM module just to set one variable.
Wow.

(OK, it also checks for new mail and displays a stupid message, but
your shell already does that, so nobody would ever want PAM to do it
too.  Probably.)

Re: Ideal place to set environment variables

[Don Armstrong]

On Fri, 30 Mar 2018, Greg Wooledge wrote:
> I have an extremely simple real-world litmus test which every system
> I've ever seen so far has failed:
> 
>   How do I set MAIL=$HOME/Maildir/ in the login environment of every
>   user, regardless of their shell, or how they log in (console, ssh,
>   X Display Manager, GNOME Display Manager, etc.)?
> 
> That's it.  Simple, right?  But login.conf can't do it.  And pam_env.so
> can't do it.  They only allow static strings with no substitutions.

pam_env.so can do substitutions, like:

MAIL DEFAULT=${HOME}/Maildir

Though that assumes that HOME was actually set (probably not) at the
time that pam_env fires. Recent versions of pam env have a PAM_ITEM
@{HOME}, which calls pam_modutil_getpwnam, which should return the HOME
directory in all cases. [Oddly, this isn't documented in the manpage,
but it's there in the source code.]

In this case, you likely really want pam_mail, and something like:

session optional pam_mail.so dir=~/Maildir nopen

which should DTRT.


-- 
Don Armstrong  https://www.donarmstrong.com

"The trouble with you, Ibid" he said, "is that you think you're the
biggest bloody authority on everything"
 -- Terry Pratchet _Pyramids_ p146

Re: Ideal place to set environment variables

[Stefan Monnier]

> I have an extremely simple real-world litmus test which every system
> I've ever seen so far has failed:
>
>   How do I set MAIL=$HOME/Maildir/ in the login environment of every
>   user, regardless of their shell, or how they log in (console, ssh,
>   X Display Manager, GNOME Display Manager, etc.)?
>
> That's it.  Simple, right?  But login.conf can't do it.  And pam_env.so
> can't do it.  They only allow static strings with no substitutions.
> In fact I'm not aware of ANYTHING that can do it.

And the sad fact is that this ridiculous situation has been with us for
more than 20 years.  Better yet: MacOSX managed to reproduce this
blunder, despite having an easy shot at doing it right.

Anyone wants to bet if/when systemd/logind will finally provide a solution?


Stefan

Re: Ideal place to set environment variables

[David Wright]

On Fri 30 Mar 2018 at 09:59:22 (-0400), Greg Wooledge wrote:
> On Thu, Mar 29, 2018 at 09:42:34PM +0100, Jonathan de Boyne Pollard wrote:
> > I think that login.conf is a step in the right direction, and I'm planning
> > on making tools that support it.  Or, rather, on making the tools that
> > already support it on the BSDs also support it on Linux operating systems.
> > 
> > * http://netbsd.gw.com/cgi-bin/man-cgi?login.conf
> > 
> > * https://www.freebsd.org/cgi/man.cgi?query=login.conf
> > 
> > * https://man.openbsd.org/login.conf
> > 
> > * http://jdebp.eu./Softwares/nosh/guide/userenv-fromenv.html
> > 
> > I already use them to set the GUI environment from login.conf on TrueOS.
> > 
> > * https://unix.stackexchange.com/a/390089/5132
> 
> I have an extremely simple real-world litmus test which every system
> I've ever seen so far has failed:
> 
>   How do I set MAIL=$HOME/Maildir/ in the login environment of every
>   user, regardless of their shell, or how they log in (console, ssh,
>   X Display Manager, GNOME Display Manager, etc.)?
> 
> That's it.  Simple, right?  But login.conf can't do it.  And pam_env.so
> can't do it.  They only allow static strings with no substitutions.
> In fact I'm not aware of ANYTHING that can do it.
> 
> The closest I've seen is sshd_config which uses %h and %u tokens in
> some contexts, but only for specific sshd configuration parameters --
> not for setting environment variables.
> 
> In the real world, today, the only solution is to duplicate that setting
> in multiple places, so that (hopefully) every conceivable login method +
> shell combination will pick up at least one of them.

A shotgun approach may work well for something like   MAIL=$HOME/Maildir/
where you *always* want it set, and setting it again has no side-effects.
But a more focussed approach is necessary when setting, say, PATH.

Cheers,
David.

Re: Ideal place to set environment variables

[Greg Wooledge]

On Thu, Mar 29, 2018 at 09:42:34PM +0100, Jonathan de Boyne Pollard wrote:
> I think that login.conf is a step in the right direction, and I'm planning
> on making tools that support it.  Or, rather, on making the tools that
> already support it on the BSDs also support it on Linux operating systems.
> 
> * http://netbsd.gw.com/cgi-bin/man-cgi?login.conf
> 
> * https://www.freebsd.org/cgi/man.cgi?query=login.conf
> 
> * https://man.openbsd.org/login.conf
> 
> * http://jdebp.eu./Softwares/nosh/guide/userenv-fromenv.html
> 
> I already use them to set the GUI environment from login.conf on TrueOS.
> 
> * https://unix.stackexchange.com/a/390089/5132

I have an extremely simple real-world litmus test which every system
I've ever seen so far has failed:

  How do I set MAIL=$HOME/Maildir/ in the login environment of every
  user, regardless of their shell, or how they log in (console, ssh,
  X Display Manager, GNOME Display Manager, etc.)?

That's it.  Simple, right?  But login.conf can't do it.  And pam_env.so
can't do it.  They only allow static strings with no substitutions.
In fact I'm not aware of ANYTHING that can do it.

The closest I've seen is sshd_config which uses %h and %u tokens in
some contexts, but only for specific sshd configuration parameters --
not for setting environment variables.

In the real world, today, the only solution is to duplicate that setting
in multiple places, so that (hopefully) every conceivable login method +
shell combination will pick up at least one of them.

Re: Ideal place to set environment variables

[Jonathan de Boyne Pollard]

Greg Wooledge:

If there existed a single, universal, simple answer, don't you think 
we would have put it on the wiki page?




I think that login.conf is a step in the right direction, and I'm 
planning on making tools that support it.  Or, rather, on making the 
tools that already support it on the BSDs also support it on Linux 
operating systems.


* http://netbsd.gw.com/cgi-bin/man-cgi?login.conf

* https://www.freebsd.org/cgi/man.cgi?query=login.conf

* https://man.openbsd.org/login.conf

* http://jdebp.eu./Softwares/nosh/guide/userenv-fromenv.html

I already use them to set the GUI environment from login.conf on TrueOS.

* https://unix.stackexchange.com/a/390089/5132

Re: Ideal place to set environment variables

[Subhadip Ghosh]

Hello Ben,

Your login manager invokes the correct script based on the selected 
desktop, and your personal one in ~/.config/xfce4/xinitrc takes 
precedence over /etc/xdg/xfce4/xinitrc . The last line just tells sh 
to source (run) the official /etc/xdg/xfce4/xinitrc , but you get to 
set your environment variables *first* so they affect everything in 
Xfce including services and desktop components. I do not know if this 
is documented succinctly in one place, but that is my understanding of 
how it works. 
Your understanding is correct. A quick Googling gave some helpful 
results. Take a look at the 'How to customize starting Xfce' section at 
the below link:


https://wiki.xfce.org/tips

Thank you for sharing it with me.

Thanks,
Subhadip


On Tuesday 20 March 2018 09:05 AM, Ben Caradoc-Davies wrote:

On 20/03/18 16:13, Subhadip Ghosh wrote:

Hi Ben,

Under XFCE, I have ~/.config/xfce4/xinitrc something like this:
#!/bin/sh
export LC_COLLATE=C
export PATH=$HOME/bin:$PATH
export QT_QPA_PLATFORMTHEME=gtk2
export GTK_OVERLAY_SCROLLING=0
umask 007
. /etc/xdg/xfce4/xinitrc 
Thanks for telling me this. Since I also use Xfce, it makes sense for 
me to go this route. Can you tell me where I can read more about this 
file preferably in the context of Xfce?


This is a standard xinit script (like ~/.xinitrc, see "man xinit") but 
to support switching between different desktops, scripts in /etc 
follow XDG rather than having a single ~/.xinitrc :

https://wiki.archlinux.org/index.php/XDG_Base_Directory_support

Your login manager invokes the correct script based on the selected 
desktop, and your personal one in ~/.config/xfce4/xinitrc takes 
precedence over /etc/xdg/xfce4/xinitrc . The last line just tells sh 
to source (run) the official /etc/xdg/xfce4/xinitrc , but you get to 
set your environment variables *first* so they affect everything in 
Xfce including services and desktop components. I do not know if this 
is documented succinctly in one place, but that is my understanding of 
how it works.


Kind regards,

Re: Ideal place to set environment variables

[Ben Caradoc-Davies]

On 20/03/18 16:13, Subhadip Ghosh wrote:

Hi Ben,

Under XFCE, I have ~/.config/xfce4/xinitrc something like this:
#!/bin/sh
export LC_COLLATE=C
export PATH=$HOME/bin:$PATH
export QT_QPA_PLATFORMTHEME=gtk2
export GTK_OVERLAY_SCROLLING=0
umask 007
. /etc/xdg/xfce4/xinitrc 
Thanks for telling me this. Since I also use Xfce, it makes sense for me 
to go this route. Can you tell me where I can read more about this file 
preferably in the context of Xfce?


This is a standard xinit script (like ~/.xinitrc, see "man xinit") but 
to support switching between different desktops, scripts in /etc follow 
XDG rather than having a single ~/.xinitrc :

https://wiki.archlinux.org/index.php/XDG_Base_Directory_support

Your login manager invokes the correct script based on the selected 
desktop, and your personal one in ~/.config/xfce4/xinitrc takes 
precedence over /etc/xdg/xfce4/xinitrc . The last line just tells sh to 
source (run) the official /etc/xdg/xfce4/xinitrc , but you get to set 
your environment variables *first* so they affect everything in Xfce 
including services and desktop components. I do not know if this is 
documented succinctly in one place, but that is my understanding of how 
it works.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: Ideal place to set environment variables

[Subhadip Ghosh]

Hi Ben,


Under XFCE, I have ~/.config/xfce4/xinitrc something like this:

#!/bin/sh
export LC_COLLATE=C
export PATH=$HOME/bin:$PATH
export QT_QPA_PLATFORMTHEME=gtk2
export GTK_OVERLAY_SCROLLING=0
umask 007
. /etc/xdg/xfce4/xinitrc 
Thanks for telling me this. Since I also use Xfce, it makes sense for me 
to go this route. Can you tell me where I can read more about this file 
preferably in the context of Xfce?


Thanks,
Subhadip

On Tuesday 20 March 2018 03:23 AM, Ben Caradoc-Davies wrote:

On 20/03/18 07:59, Subhadip Ghosh wrote:

While it was very informative, it was not evident from it that what
the standard or preferred place is for setting an environment variable
if I want it to be available from both graphical applications as well as
from terminal (bash).


Under XFCE, I have ~/.config/xfce4/xinitrc something like this:

#!/bin/sh
export LC_COLLATE=C
export PATH=$HOME/bin:$PATH
export QT_QPA_PLATFORMTHEME=gtk2
export GTK_OVERLAY_SCROLLING=0
umask 007
. /etc/xdg/xfce4/xinitrc

Graphical applications (including xfce4-teminal) and its child bash 
inherit these exported environment variables from their parent. (And 
note that I assume $PATH and $HOME do not require quoting.)


The file is a script so it must be executable:
chmod 700 ~/.config/xfce4/xinitrc

Kind regards,

Re: Ideal place to set environment variables

[Ben Caradoc-Davies]

On 20/03/18 07:59, Subhadip Ghosh wrote:

While it was very informative, it was not evident from it that what
the standard or preferred place is for setting an environment variable
if I want it to be available from both graphical applications as well as
from terminal (bash).


Under XFCE, I have ~/.config/xfce4/xinitrc something like this:

#!/bin/sh
export LC_COLLATE=C
export PATH=$HOME/bin:$PATH
export QT_QPA_PLATFORMTHEME=gtk2
export GTK_OVERLAY_SCROLLING=0
umask 007
. /etc/xdg/xfce4/xinitrc

Graphical applications (including xfce4-teminal) and its child bash 
inherit these exported environment variables from their parent. (And 
note that I assume $PATH and $HOME do not require quoting.)


The file is a script so it must be executable:
chmod 700 ~/.config/xfce4/xinitrc

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: Ideal place to set environment variables

[Greg Wooledge]

On Tue, Mar 20, 2018 at 12:29:53AM +0530, Subhadip Ghosh wrote:
> I went through the below link:
> 
> https://wiki.debian.org/EnvironmentVariables
> 
> While it was very informative, it was not evident from it that what
> the standard or preferred place is for setting an environment variable
> if I want it to be available from both graphical applications as well as
> from terminal (bash).

Well, that's the problem: there isn't a single place that is read by
both kinds of logins (shell and Display Manager).  And don't even get
us started on GNOME.

> I would prefer to set it at a single location.

Such a thing does not exist.  You'll have to choose one and then "dot
it in" from the other one.  Or choose a third location and "dot it in"
from both of the places that are actually used.

(That still won't save you from GNOME's stupidity, of course.)

If there existed a single, universal, simple answer, don't you think
we would have put it on the wiki page?

Ideal place to set environment variables

[Subhadip Ghosh]

Hi,

I went through the below link:

https://wiki.debian.org/EnvironmentVariables

While it was very informative, it was not evident from it that what
the standard or preferred place is for setting an environment variable
if I want it to be available from both graphical applications as well as
from terminal (bash).

I would prefer to set it at a single location. And also I would prefer
not to change a bunch of other files so that one file where I am setting
the variables gets called from other places.

Also, since the environmental variable is going to be user specific, it
should be under the user's home.

Any pointer in the right direction is much appreciated.

Thanks,
Subhadip