/etc/environment PATH should not have quotes

[Jae Jang]

installed 8.04 server edition on a desktop and 8.04.1 desktop edition on a laptop, both fully updated.

both have the line PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"
inside /etc/environment

while this works for 99% of the time these days, in some rare cases, the quotes are taken literally and the string isn't fully expanded.

specifically, using rsh/rlogin (even more specifically, I'm using the kerberized versions in krb5-clients package) on a server results in the PATH actually being "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games", i.e. one long invalid directory, instead of expanded version, /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games (6 separate directories).

again, this isn't a problem for most use cases like a regular bash login or ssh, since they seem to evaluate it down to what's valid, but there doesn't seem to be any real reason to have the quotes in there....?

some may not even notice it being incorrect after rlogin, since the bash invalid command fallback will fill in most usual locations like /usr/bin. however try running something in /usr/games, like say... banner and it will complain.

solution is to just remove the two " characters in the line. works for me.

[Colin Watson (cjwatson)]

This is created by the libpam-modules postinst.

Please separately report any bugs you've encountered due to the quotes; anything that uses /etc/environment should be doing so according to pam_env's rules (even if they don't actually use pam_env) and should be fixed if it doesn't match up.

[Steve Langasek (vorlon)]

This behavior has persisted in /etc/environment now for at least 3 years, with only one report of misbehavior as a result. I don't believe it's worth the effort to try to correct this now and risk getting inconsistent behavior on upgraded vs. newly-installed systems, especially as pam_env, which owns /etc/environment, *does* parse out the quotes from variable assignments.

If something else is reading /etc/environment directly, bypassing pam_env, and parsing it differently than pam_env itself does, then as Colin says, this is a bug in that component. I'm therefore reassigning this bug report to the krb5 package, as this needs to be fixed in krb5-rsh-server.

[Sam Hartman (hartmans)]

So, fixing this particular bug in krb5-rsh-server is almost certainly
relatively easy. Fixing krb5-rsh-server to use PAM directly is more
involved; it should be done, but there is not a lot of resources going
into krb5-rsh-server and krb5-clients at the moment. Upstream split
these into the krb5-appl package in significant part to provide a lower
level of support for these packages.

The code in question is in bsd/login.c in the krb5-appl
package. Particularly, look at the read_env_vars_from_file function.
I don't have time right now to generate a patch or test it, but I wanted
to document where to look because I did have that time.

--Sam

[Clint Byrum (clint-fewbar)]

Reading the code as suggested by Sam, I see that everything after "=" and before a newline is copied into the environment using 'setenv()'. So no quote expansion is done. I'm not sure what the fix is, but there's certainly the possibility that programs will misinterpret this. I'm marking it as Confirmed in krb5. The simple fix would be to add very basic quote expansion. The code in pam that does this does not support escaped quotes, and is not exposed as an extermal library, so I think its safe to just copy that.

Marking Confirmed, also adding krb5-appl since it has been split out since 10.10.

I'm attaching a patch which might solve it, but I am not sure how to test it.