Solved Using sysutils/pam_xdg, but $XDG_xxx vars are not updating upon "su" (and maybe in other situations too)

rwv37

rwv37

I'm using sysutils/pam_xdg to set the various $XDG_xxx variables for shells. The man page for it says you should probably insert the following line into the session sections of various /etc/pam.d config files:
Code: 
session optional pam_xdg.so notroot track_sessions
I have done that (in all the suggested files, including /etc/pam.d/su), with one modification: I did not include the notroot option. I did this because:

(1) The man page says that if notroot is used, "the module will bypass itself for root account logins and perform no actions for root", and

(2) I want it to operate for root.

When I log into my main account (bob), the $XDG_xxx vars are set up as I expect. For example:
Code: 
$ echo $XDG_CONFIG_HOME
/home/bob/.config
But when I then do a su, the variable is unchanged:
Code: 
# echo $XDG_CONFIG_HOME
/home/bob/.config

This... does not seem good, as now root will use bob's config and whatnot (including, for a particularly bad example, gpg config). This sort of possible behavior is exactly why I had decided to get rid of notroot in the first place.

I have also tried it with notroot, just in case the problem was a "checking a boolean against the wrong value" sort of bug. This did not help. Also, I tried shutting down the machine and booting from scratch; this also did not help.

Like I said, I added that line to all of the suggested /etc/pam.d files, which are: system, login, sshd, and su. Is there perhaps some other file that I should also add it to? I had imagined that adding it to su would handle it for the case of when a su command is issued.

Or are there perhaps (seemingly) unrelated factors at play here? Like, maybe there's some other pam setting that stops it from happening for root? I strongly believe that adding this line to the specified files was the only change I've ever made to pam configuration, so everything else should be the FreeBSD 13.1 default. And to be clear, I really do mean "ever" - not merely "ever on this particular machine". I'm essentially a total pam newbie.

Any help would be appreciated. Thanks in advance.
 
Thanks, but are you suggesting that there's no way to get pam_xdg to update the variables on a non-login shell (like from a standard, default su command)? This would come as a surprise to me, because:

(1) If it doesn't handle the non-login case, then obviously serious problems like this will occur, and

(2) The man page says (emphasis mine, and the "runtime" here refers to another option of pam_xdg): "Unless runtime was given all XDG related environment variables will be created in all user sessions with their default or computed values, otherwise only XDG_RUNTIME_DIR."
 
The man page for su(1) says "By default, the environment is unmodified with the exception of USER, HOME, and SHELL". If you choose to use "su -" (or "su -l") the full login process for the chosen user will be simulated. You have discovered a feature, not a bug...
 
I know that, but I fail to see why the "default" for su cannot, or should not, be overridden. Specifically, for example, by a pam module that (apparently) is supposed to be used when a su is done.

Does no one who uses xdg ever use a non-login shell? I feel like I'm missing something here, because the situation seems absurd. It's a totally obvious thing that this behavior would cause problems, including potentially serious security issues. And if it's intentional, and the only reason for it is "well, by default, su doesn't update most environment variables", that... doesn't seem like a good reason to me.
 
Many people, when using su, don't want their environment crapped upon... because that can lead to all sorts of surprises... when you are root!
 
Sure, but when there's a system-wide thing that is responsible for setting up the proper values of environment variables such as where the account's configuration for a zillion different software packages is kept, among other important things, having that thing operate is not "crapping on your environment". If anything, it's exactly the opposite: not having it operate is crapping on the environment.

But whatever. I'm not really interested in getting into a discussion about whether this is behavior is totally awesome or something less than totally awesome. What I'm interested in is whether or not there's a way to make pam_xdg behave in a different way with respect to this. If the answer is "no", then OK, fine, I'll give up on using pam_xdg.
 
If you're planning to login under a non-privileged account and then su to root anyway, why not just login to root to begin with and have all your settings? It's easy enough to shut X down and logout real quick then log in on another tty as a normal user. (You don't run everything under root user all the time do you??) Like what software are you running that requires root privileges all the time?
 
First, to briefly answer your specific questions:

(1) I do not allow direct root logins on my machine (as suggested in the Handbook, 14.3.1).

(2) I do not use X.

(3) Of course I don't run as root all the time, and it's not clear to me why you would jump to that conclusion.

With that said:

Again, I am not terribly interested in getting into a discussion about this; I am just interested in the answer to my question. However, I'm getting the feeling that perhaps either (A) I don't understand how XDG is supposed to work, or (B) some others in this thread don't (or perhaps do, but haven't really thought it through fully). I would not be surprised at all if (A) is the case, but no matter which of (A) or (B) is, I think it might be good to explain my understanding of how XDG is supposed to work, and to give a concrete example of what I see as the issue based upon that understanding.

As I understand it, an XDG-savvy program, let's call it savvy, is supposed to look for its configuration in these places:

(1) If $XDG_CONFIG_HOME is defined, then in $XDG_CONFIG_HOME/savvy.
(2) If it is not defined, then in $HOME/.config/savvy.

Configuration is not the only thing; similar XDG variables with associated similar rules exist for finding the locations of things like savvy's data files, cache files, state files, user-specific executable files, etc. But for the sake of simplicity, I'll continue to just use the example of configuration.

Now let's say there's another program, "polite", that is not XDG-savvy in the above sense, but is polite in the sense that it does not contribute to the common "home directory dotfile spam" thing. It looks for its configuration in $HOME/.config/polite.

Yet another program, "adhoc", has its own homebrewed rules for where it looks for its configuration. It looks in $HOME/.adhoc.

A fourth program, "graceschoolpupil", used to behave similarly to adhoc, but its authors have recently updated it to act more like saavy. But for backwards compatibility, it still supports the old location of its config files. So, it looks for configuration as so:

(1) If $XDG_CONFIG_HOME is defined, in $XDG_CONFIG_HOME/graceschoolpupil.
(2) If not, then if $HOME/.config/graceschoolpupil exists, then in $HOME/.config/graceschoolpupil.
(3) Finally, if neither of the above exists, then in $HOME/.graceschoolpupil.

Before continuing, I would like to point out two things:

(1) Programs of all four of these types exist.
(2) As mentioned above by gpw928, su DOES change $HOME, no matter whether you do it to a login shell or not.

Now let's say the machine is not set up to know about XDG (i.e. there is nothing like pam_xdg that sets the $XDG_xxx variables). I log in as bob. My programs now find their configuration in:

$HOME/.config/savvy
$HOME/.config/polite
$HOME/.adhoc
$HOME/.config/graceschoolpupil, or if that doesn't exist, $HOME/.graceschoolpupil

Specifically, those are:

/home/bob/.config/savvy
/home/bob/.config/polite
/home/bob/.adhoc
/home/bob/.config/graceschoolpupil, or if that doesn't exist, /home/bob/.graceschoolpupil

Now I su to root (or to anything, really; it doesn't really matter with regards to my point that it necessarily be to root). Not necessarily a "su -"; just a plain old "su", perhaps. Since su, unadorned or not, DOES change $HOME,my programs will now find their configuration in:

/root/.config/savvy
/root/.config/polite
/root/.adhoc
/root/.config/graceschoolpupil, or if that doesn't exist, /root/.graceschoolpupil

This is the totally normal and expected behavior: Doing a "su" changes where the vast majority of programs will look for their configuration, no matter whether you su into a login shell or not. And again, this is the normal, default behavior of a FreeBSD system; if you don't want FreeBSD to act this way, you have to explicitly make FreeBSD not act this way.

Sometime later, I have updated my machine to use sysutils/pam_xdg. The intent of this package, as I understand it, is to explicitly set up users' $XDG_xxx variables, to the same values that would be used by XDG-savvy programs in the case that the variables did not exist.

I log in as bob. My programs now look for their configuration in:

$XDG_CONFIG_HOME/savvy
$HOME/.config/polite
$HOME/.adhoc
$XDG_CONFIG_HOME/graceschoolpupil, or if that doesn't exist, $HOME/.graceschoolpupil

Which all resolve to the same things that they did before:

/home/bob/.config/savvy
/home/bob/.config/polite
/home/bob/.adhoc
/home/bob/.config/graceschoolpupil, or if that doesn't exist, /home/bob/.graceschoolpupil

So that's cool.

But now I do an unadorned su to root, and my programs now look for their configurations in:

/home/bob/.config/savvy
/root/.config/polite
/root/.adhoc
/home/bob/.config/graceschoolpupil, or if that doesn't exist, /root/.graceschoolpupil

This is totally nonstandard behavior (especially so for graceschoolpupil), and seems to me to be obviously potentially problematic.

Again, I would not be surprised at all to learn that my understanding here is incorrect. If so, I'd appreciate if someone would point out how. If not, then again, I'm really just interested in hearing whether or not there's a way to make sysutils/pam_xdg behave as I had expected it would.
 
Or you don't want to change environment and use "su".
(Handy if you want to launch an X-application)

Or you want to change environment and use "su -".
(Handy if you want to compile the kernel)
 
rwv37 said:
(1) I do not allow direct root logins on my machine (as suggested in the Handbook, 14.3.1).
Click to expand...

Yeah... I was talking about logging into root on a console. IMO you rely on "su' too much (and PAM as well) to configure your system. What I was saying was.. why would you login to an account, then "su" to another user to load all user #2's config files and environment. Wouldn't it be much simpler and better to just log in as the user you plan to "su" to?
 
As I've mentioned before, this is the first time I've ever explicitly used PAM, so I'm not sure how you've concluded that I rely on it "too much". I am now trying to use PAM, for the first time ever, because that seems to be the suggested way to propagate XDG_xxx variables to all users. I'm also not sure how you have concluded that I "rely on su too much" - this behavior is potentially problematic no matter how often or how little you use su.

In any case, whatever. I am, again, not interested in an argument about things like whether or not my typical usages of the root account are bad. You apparently think they are. I am not sure why you think you know what my typical usages of the root account are in the first place, but fine, so noted, you think they're bad, acknowledged. Could we please now stop with the sidetracking about my habits?
 
covacat, great, thank you, that explains the issue. I was not aware of this (like I said, this is my first explicit usage of pam).
 
rwv37 said:
In any case, whatever. I am, again, not interested in an argument about things like whether or not my typical usages of the root account are bad.
Click to expand...

That still doesn't answer my question why you would configure two separate users each with unique configs, log in as one user, then "su" to another user to load a totally different environment and all their variables. Isn't that why you separated the configs into different accounts in the first place? I was trying to give you a simple workaround... log in as a user on the console and keep all your settings / configuration. When you want user #2's config, log in via console as that user.

rwv37 said:
I am not sure why you think you know what my typical usages of the root account are in the first place
Click to expand...

Because you hinted that you can't go into a console and log in as "root". Yeah that's pretty bad.

You seem dead set on making your system complicated and messy, and you're not interested in simple workarounds or things that make sense to do. I'm becoming less and less interested on why you do the things you do and the motivations behind those actions. This is a forum, so you're going to get different opinions on your issues / questions. It's not a 1-800 number for technical support. Good luck.
 
Jesus, dude, I did not say that I couldn't go to a console and log in as root. I can do so. I don't even know if it's possible to not be able to (unless of course you don't have physical access to the machine).

What I can't do, as is a pretty standard way to set up a system, is to (for example) sshd directly into root. If I want to do something as root, I can get up off of my nice comfy couch and walk all the way to my server room with the old uncomfortable chair that I almost never use, but I'm extremely lazy and moreover I like my nice comfy couch. A lot more than I like my old uncomfortable chair that I almost never use.
That still doesn't answer my question (...)
Click to expand...
I did not start this thread so that you could keep repeatedly asking me about (and making your own broad, incorrect assumptions about) my habits. But since you keep insisting on doing so (emphasis mine):
That still doesn't answer my question why you would configure two separate users each with unique configs, log in as one user, then "su" to another user to load a totally different environment and all their variables.
Click to expand...
The XDG scheme does NOT, and IS NOT INTENDED TO, change "all your variables". Moreover I've never suggested that it did, or that I wanted it to. I'm not saying that pam_xdg should force all usages of su to be equivalent to "su -". I'm saying that it should allow a way to have all usages of su, whether to a login shell or not, to act the way that they do in a default FreeBSD system. That is:

In a default FreeBSD system, out of the box without any changes at all, "su -" will change all of your variables, yes. But it is not true that, as you seem to think, a plain unadorned su will not change any of those values. It changes $HOME, for example. And since XDG is used to set up certain other variables based on the value of $HOME, the result is that if you install pam_xdg, a plain unadorned su will no longer be functionally equivalent to the default behavior of su. It will leave you with a weird mishmash of "some programs pull config from /root, some others pull it from /home/chessguy64, and for still other programs from /home/chessguy64 unless the config can't be found there, in which case from /root".

The actual question has already been answered, so can you please just drop it now? Or are you for some reason still strangely and insistently curious about my personal habits? If the latter, could you perhaps email me about whether I like my coffee with or without sugar, instead of just repeatedly coming to this thread based on a specific question, not having to do with my coffee preferences, with that specific question already having been answered, to just keep telling me that my coffee preferences, which I have never told you, suck?

This is the last reply I will make in this thread in response to any further comments that are about how I like my coffee instead of about, you know, the actual question of the thread. No sugar, by the way, and black.
 
rwv37 said:
It will leave you with a weird mishmash of "some programs pull config from /root, some others pull it from /home/chessguy64, and for still other programs from /home/chessguy64 unless the config can't be found there, in which case from /root".
Click to expand...

That's why I suggested not using su, and logging into the account the traditional way. Since you're lazy, I thought that would be a good and simple option for you.

I didn't see your email in your profile, but something tells me that if I email you about coffee you will swear that your way of making coffee is the best, and you won't even listen to my suggestions on brew methods / techniques. I drink coffee with sugar and light cream btw.
 
Hello, by sheer accident i saw this, and registered for that. I am not used to forums, so.
I wrote this little thing.
I understand your thoughts and you are right, *however*, look at this:

Mar 19 21:39:28 (none) su[3049]: pam_unix(su:session): session opened for user root(uid=0) by (uid=1000)
Mar 19 21:39:28 (none) su[3049]: pam_xdg(su:session): pam_xdg: SESSION OPEN
Mar 19 21:39:28 (none) su[3049]: pam_xdg(su:session): PUTENV <XDG_RUNTIME_DIR>
Mar 19 21:39:28 (none) su[3049]: pam_xdg(su:session): pam_putenv: delete non-existent entry; XDG_RUNTIME_DIR
Mar 19 21:39:28 (none) su[3049]: pam_xdg(su:session): pam_xdg: user root: pam_putenv(): Bad item passed to pam_*_item()
Mar 19 21:39:28 (none) su[3049]: pam_xdg(su:session): PUTENV <XDG_CACHE_HOME>
Mar 19 21:39:28 (none) su[3049]: pam_xdg(su:session): pam_putenv: delete non-existent entry; XDG_CACHE_HOME
Mar 19 21:39:28 (none) su[3049]: pam_xdg(su:session): pam_xdg: user root: pam_putenv(): Bad item passed to pam_*_item()
Mar 19 21:39:28 (none) su[3049]: pam_xdg(su:session): PUTENV <XDG_CONFIG_DIRS>
Mar 19 21:39:28 (none) su[3049]: pam_xdg(su:session): pam_putenv: delete non-existent entry; XDG_CONFIG_DIRS
Mar 19 21:39:28 (none) su[3049]: pam_xdg(su:session): pam_xdg: user root: pam_putenv(): Bad item passed to pam_*_item()
Mar 19 21:39:28 (none) su[3049]: pam_xdg(su:session): PUTENV <XDG_CONFIG_HOME>
Mar 19 21:39:28 (none) su[3049]: pam_xdg(su:session): pam_putenv: delete non-existent entry; XDG_CONFIG_HOME
Mar 19 21:39:28 (none) su[3049]: pam_xdg(su:session): pam_xdg: user root: pam_putenv(): Bad item passed to pam_*_item()
Mar 19 21:39:28 (none) su[3049]: pam_xdg(su:session): PUTENV <XDG_DATA_DIRS>
Mar 19 21:39:28 (none) su[3049]: pam_xdg(su:session): pam_putenv: delete non-existent entry; XDG_DATA_DIRS
Mar 19 21:39:28 (none) su[3049]: pam_xdg(su:session): pam_xdg: user root: pam_putenv(): Bad item passed to pam_*_item()
Mar 19 21:39:28 (none) su[3049]: pam_xdg(su:session): PUTENV <XDG_DATA_HOME>
Mar 19 21:39:28 (none) su[3049]: pam_xdg(su:session): pam_putenv: delete non-existent entry; XDG_DATA_HOME
Mar 19 21:39:28 (none) su[3049]: pam_xdg(su:session): pam_xdg: user root: pam_putenv(): Bad item passed to pam_*_item()
Mar 19 21:39:28 (none) su[3049]: pam_xdg(su:session): PUTENV <XDG_STATE_HOME>
Mar 19 21:39:28 (none) su[3049]: pam_xdg(su:session): pam_putenv: delete non-existent entry; XDG_STATE_HOME
Mar 19 21:39:28 (none) su[3049]: pam_xdg(su:session): pam_xdg: user root: pam_putenv(): Bad item passed to pam_*_item()

This was due to

#?0|kent:toolbox.git$ su
Password:
#?0|kent:toolbox.git$ whoami
root
#?0|kent:toolbox.git$ env|grep XDG
XDG_CONFIG_DIRS=/etc/xdg
XDG_DATA_HOME=/run/user/1000/.local/share
XDG_CONFIG_HOME=/home/steffen/.config
XDG_CACHE_HOME=/home/steffen/.cache
XDG_STATE_HOME=/home/steffen/.local/state
XDG_RUNTIME_DIR=/run/user/1000
XDG_DATA_DIRS=/usr/local/share:/usr/share

So, at least with Linux PAM: no way to do what you want.
 
Hello.
Even though no longer necessary because FreeBSD ships now with a different pam_xdg in base (even though that is only _runtime, but is not named so, like all the other pam/XDG/runtime-only, ie dumb_runtime_dir, or pam-rundir, or what; but, 'nuff!).
Funnily it is not even possible first set and then unset via PAM.
But what is possible is plain unsetenv(3), so i just released v0.8.3 which does exactly that for "notroot".
Without any credit to you, rwv37! Please send a private email to as via pam_xdg(8) if you want to see your credit.

Thank you!!
 
You must log in or register to reply here.
Back
Top