currently we let through a lot of env vars that don't make sense: static const char *const env_whitelist[] = { "CONSOLE", "PATH", "SHELL", "USER", "HOME", "TERM", "LANG", "LC_CTYPE", "LC_NUMERIC", "LC_TIME", "LC_COLLATE", "LC_MONETARY", "LC_MESSAGES", "LC_PAPER", "LC_NAME", "LC_ADDRESS", "LC_TELEPHONE", "LC_MEASUREMENT", "LC_IDENTIFICATION", "LC_ALL", "IN_HOTPLUG", "IN_BACKGROUND", "RC_INTERFACE_KEEP_CONFIG", "EERROR_QUIET", "EINFO_QUIET", NULL }; why would we want any of these to be passed down ? it means an init script started at boot will get a very diff env from one started by the user (via sudo or other means). especially the USER/HOME settings -- it means some daemons might start poking around ~/ to change their behavior or save state.
Honestly, I'm not sure why we are passing these down, so I will remove them in 0.20.
@vapier: https://github.com/openrc/openrc/commit/53bc986 takes care of most of these. The variables I left are the openrc and einfo related ones. On a related note, we pass everything through that we find in /etc/profile.env as well, and I'm wondering if we should do that; I'm thinking the answer should be no for the same reasons. What do you think?
(In reply to William Hubbs from comment #2) profile.env is the common source we have currently for "system" env vars and is built by merging /etc/env.d/*. this is what allows people to configure things like global default locales. on pam based systems, there is also /etc/environment which is processed by pam_env and loaded by all the standard system modules (session/auth/etc...). but on non-pam systems, we only have profile.env. i agree that file is kind of fat. we should actively look into other data stores for some of these settings, but we'd still want openrc to load the file for us.
Ok, I'll go ahead and close this for now then, the commit above is the only change that is going to be in 0.20. Thanks, William
