macOS environment.plist: key/values persist after deletion & relogging?!

[3460169]

This seemed like the most appropriate forum to post this... concern. In short: is there any particular reason that environment variables set via ~/.MacOSX/environment.plist persist even after they've been removed from the plist and the user has logged out & back in? It seems the only way to clear them from the user's environment is for the machine to rebooted!

Simply unsetting the vars from the user's shell isn't sufficient for obvious reasons, and setting to an empty string isn't either. Any thoughts on this? And what process, exactly, is maintaining those environment variables in memory? FWIW this behavior exists on SL and Lion.

Cheers,

 

[chown33]

This seemed like the most appropriate forum to post this... concern. In short: is there any particular reason that environment variables set via ~/.MacOSX/environment.plist persist even after they've been removed from the plist and the user has logged out & back in? It seems the only way to clear them from the user's environment is for the machine to rebooted!

I confirmed this in Snow Leopard. I also confirmed it doesn't happen in Leopard or Tiger. Logout and login is sufficient to eliminate the deleted env-var.

If I had to guess, this seems like a bug to me. You could file a bug report, but considering that Snow Leopard is likely to be dead for anything other than security fixes, I don't recommend waiting for a fix.

Simply unsetting the vars from the user's shell isn't sufficient for obvious reasons, and setting to an empty string isn't either. Any thoughts on this?

Why isn't unsetting the vars sufficient? An 'unset' in the shell removes it as a shell variable and an env-var. Children of that shell then inherit that shell's env vars. I tested this, and it works here. Please confirm or refute with testing at your end.

A work-around might be setting the value to "" in the plist, but you'd have to explain how you're using the env-var. Depending on how it's used, there might be a way to make an empty value the same as an undefined value.

And what process, exactly, is maintaining those environment variables in memory?

Guessing again, I'd say the per-user login or launchd process.

 

[3460169]

I confirmed this in Snow Leopard. I also confirmed it doesn't happen in Leopard or Tiger. Logout and login is sufficient to eliminate the deleted env-var.

Thanks for testing.

If I had to guess, this seems like a bug to me. You could file a bug report, but considering that Snow Leopard is likely to be dead for anything other than security fixes, I don't recommend waiting for a fix.

Indeed it looks like a bug. I discovered it because I needed to set an HTTPS_PROXY environment variable for use with github's client, as a workaround for some network issues we've been having. Our proxy requires authorization and hence I needed to embed my username/password in that environment variable (which of course is plain text). This obviously isn't security conscious but I had no choice at the time. Once we no longer needed the proxy, I removed the env var from the plist and it proceeded to remain in the environment after relogging and I was highly disturbed that my credentials were still there even after I believed they were removed.

Why isn't unsetting the vars sufficient? An 'unset' in the shell removes it as a shell variable and an env-var. Children of that shell then inherit that shell's env vars. I tested this, and it works here. Please confirm or refute with testing at your end.

For programs started that have the shell as an ancestor it's fine. I can certainly unset env vars to my liking via ~/.bash_profile or ~/.bashrc. For apps started via the GUI (Dock, Finder, Spotlight, etc) -- they will have whatever environment was passed to it by loginwindow.

A work-around might be setting the value to "" in the plist, but you'd have to explain how you're using the env-var. Depending on how it's used, there might be a way to make an empty value the same as an undefined value.

Sure. Setting it to empty might be fine, if and only if whatever app is looking for the env var treats an empty var as an being unset/undefined. But this likely isn't always the case. I don't have any examples where an app would treat an empty value differently from an undefined value.

Regardless, this is definitely unexpected behavior that I hoped to find an explanation for. I'll submit a bug report.

Guessing again, I'd say the per-user login or launchd process.

Launchd. Probably an accurate guess...

 

[chown33]

Indeed it looks like a bug. I discovered it because I needed to set an HTTPS_PROXY environment variable for use with github's client, as a workaround for some network issues we've been having.

App-specific env-vars can be predefined in the app's Info.plist:
http://developer.apple.com/library/...BPRuntimeConfig/Articles/EnvironmentVars.html
It's the LSEnvironment key (a dictionary).

Assuming the env-var is only for a specific application, I would have edited the Info.plist of the app.

If the env-var is for a specific app and some shell commands, I would have edited Info.plist of the app, then set the env-var in my shell's startup script.

I only use ~/.MacOSX/environment.plist for safe (no secrets) data.

Our proxy requires authorization and hence I needed to embed my username/password in that environment variable (which of course is plain text). This obviously isn't security conscious but I had no choice at the time. Once we no longer needed the proxy, I removed the env var from the plist and it proceeded to remain in the environment after relogging and I was highly disturbed that my credentials were still there even after I believed they were removed.

I tried setting the env-var in the plist to empty, and that worked. When I deleted the empty var, it still showed up as empty. Still not what was expected, but not leaking a secret, either.

Setting it to empty might be fine, if and only if whatever app is looking for the env var treats an empty var as an being unset/undefined. But this likely isn't always the case. I don't have any examples where an app would treat an empty value differently from an undefined value.

I wasn't suggesting that it would be a universal work-around. I wouldn't expect it to be. Work-arounds are often like that: they break outside a small range.

Regardless, this is definitely unexpected behavior that I hoped to find an explanation for. I'll submit a bug report.

Since the bug appears in Lion, I'd submit it for that OS version, but also say that it appears in Snow Leopard, too. And point out it doesn't occur before Snow Leopard.

 

[3460169]

All very good suggestions, thanks!