Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 499288 - [Future EAPI]: Filter XDG / DISPLAY variables from the ebuild environment
Summary: [Future EAPI]: Filter XDG / DISPLAY variables from the ebuild environment
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: PMS/EAPI (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: PMS/EAPI
URL:
Whiteboard: in-eapi-7
Keywords:
: 567474 598547 (view as bug list)
Depends on:
Blocks: future-eapi 499202 531596 577704 584242
  Show dependency tree
 
Reported: 2014-01-26 00:08 UTC by Mike Gilbert
Modified: 2018-04-30 22:46 UTC (History)
11 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Gilbert gentoo-dev 2014-01-26 00:08:59 UTC
Portage currently sets HOME to a directory in the build tree to prevent sandbox violations from processes which write to HOME.

The XDG Base Directory Specification includes several other directories to which programs may commonly write data:

XDG_DATA_HOME
XDG_CONFIG_HOME
XDG_CACHE_HOME

These default to sub-directories of HOME if unset.

XDG_RUNTIME_DIR has no default, but applications are expected to deal with this gracefully if unset.

Can we have Portage remove these variables from the ebuild environment?
Comment 1 Mike Gilbert gentoo-dev 2014-01-26 00:16:59 UTC

*** This bug has been marked as a duplicate of bug 444568 ***
Comment 2 Mike Gilbert gentoo-dev 2014-01-26 00:30:31 UTC
Actually, I would say that filtering the variables might not need an EAPI change. Current ebuilds cannot rely on them having any specific value, so it would be perfectly acceptable for Portage to unset them.
Comment 3 Ulrich Müller gentoo-dev 2014-01-26 22:03:15 UTC
(In reply to Mike Gilbert from comment #2)
> Actually, I would say that filtering the variables might not need an EAPI
> change.

Sure it does. Otherwise things will work in Portage but break in other package managers.

What I fail to see (also in bug 444568) is how XDG_* are different from other variables (like TEXMF*)? Usually such things are better handled at the ebuild/eclass level, because the package manager cannot foresee all eventualities.

PMS defines very few variables like HOME and TMPDIR, and I think we should leave it at this.
Comment 4 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-01-26 22:14:56 UTC
Honestly? I think the problem is that we're doing opt-out here, and we won't ever be able to predict all the ways random tools will get influenced by user's environment. IMO PM should scrub the environment completely, only setting the sane build-specific variables and maybe whatever's in env.d.

Of course, this would make it impossible for our users to hack stuff like they currently do. That's a trade-off to consider.

If we want to scrub the environment, we should just create one single eclass that handles all the possibilities. Otherwise, it's just wasting developers' time guessing which variables are actually used by which tools in which versions...
Comment 5 Ulrich Müller gentoo-dev 2014-01-26 22:30:22 UTC
(In reply to Michał Górny from comment #4)
> IMO PM should scrub the environment completely, only setting the sane
> build-specific variables and maybe whatever's in env.d.

Scrubbing the environment would be throwing the baby out with the bath-water.

> Of course, this would make it impossible for our users to hack stuff like
> they currently do. That's a trade-off to consider.

You rely on such "hacks" in your own eclasses. EVCS_OFFLINE is one example.
Comment 6 Ciaran McCreesh 2014-01-26 22:36:21 UTC
To be fair, the baby is a large part of the reason that the bath water is so messy, so maybe a dead baby isn't necessarily a bad thing here... ECVS_OFFLINE and the like can easily be handled by allowing the user to set environment variables explicitly in a bashrc. It's variables leaking in from the wider environment that are the problem, not things that have been put there on purpose.
Comment 7 Alec Warner archtester Gentoo Infrastructure gentoo-dev Security 2014-01-26 22:58:36 UTC
(In reply to Ulrich Müller from comment #3)
> (In reply to Mike Gilbert from comment #2)
> > Actually, I would say that filtering the variables might not need an EAPI
> > change.
> 
> Sure it does. Otherwise things will work in Portage but break in other
> package managers.

As I mentioned on the list; the standard doesn't define the behavior, so we are free to pick whatever behavior we want for Portage.

If ebuild authors rely on undefined behavior, well that is their problem; they should author ebuilds that follow the standard.

> 
> What I fail to see (also in bug 444568) is how XDG_* are different from
> other variables (like TEXMF*)? Usually such things are better handled at the
> ebuild/eclass level, because the package manager cannot foresee all
> eventualities.
> 
> PMS defines very few variables like HOME and TMPDIR, and I think we should
> leave it at this.
Comment 8 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-01-27 05:58:06 UTC
(In reply to Ciaran McCreesh from comment #6)
> To be fair, the baby is a large part of the reason that the bath water is so
> messy, so maybe a dead baby isn't necessarily a bad thing here...
> ECVS_OFFLINE and the like can easily be handled by allowing the user to set
> environment variables explicitly in a bashrc. It's variables leaking in from
> the wider environment that are the problem, not things that have been put
> there on purpose.

Just to be clear, I don't mind the environment variables leaking as bash variables to the ebuild. However, they should not be exported there.
Comment 9 Pacho Ramos gentoo-dev 2014-09-25 14:00:04 UTC
This filtering would also help on puntual bug reports we get related with sporadic failures because of different settings in variables like "DISPLAY" or DBUS*

Also, having variables like DISPLAY kept have some side effects like some tests being able to open windows if people is compiling from a terminal (instead of failing or relying on virtualx eclass)
Comment 10 Pacho Ramos gentoo-dev 2014-09-25 14:01:08 UTC
Regarding whether this belongs to portage or PMS... well, if finally needs PMS updating maybe could be a good candidate for eapi6 :)
Comment 11 Pacho Ramos gentoo-dev 2015-01-04 10:49:30 UTC
@pms-bugs, could this be considered for eapi6? Either the cleaning of all environment variables (and then relying on a eclass appending the needed ones) or cleaning the known variables that need to be reset (as can be seen in many of the existing ebuilds and eclasses...).
Comment 12 Ulrich Müller gentoo-dev 2015-01-04 14:10:57 UTC
In PMS section 11.1 "Defined Variables" <http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-11800011.1> we already have this:

   GZIP, BZIP, BZIP2, CDPATH, GREP_OPTIONS, GREP_COLOR and GLOBIGNORE must
   not be set.

I think the least intrusive action would be to extend this blacklist. So far we have:

   XDG_CACHE_HOME, XDG_CONFIG_HOME, XDG_DATA_HOME, XDG_RUNTIME_DIR

Since EAPI 6 will introduce eapply(), the following might be added too (perforce is mostly historical, but patch-2.7.1 still supports the variables):

   P4CONFIG, P4PORT, P4USER

Anything else?
Comment 13 Pacho Ramos gentoo-dev 2015-01-05 10:46:10 UTC
We are having problems also with DBUS_SESSION_BUS_ADDRESS and DISPLAY being set to random values depending on each setup, then, they should probably be added to that blacklist to get the "unset" by default.

The problem is that we are finding offending variables when we hit the problems and sometimes they are a bit hard to find (sometimes we get a segmentation fault on a test and, after a long time, we notice it was caused by a wrong DBUS_SESSION_BUS_ADDRESS ...)

Then, I think that maybe would be better to use the "inverse" logic, I mean: set the set of variables we know what values they need to have and drop all the others. That would make all a bit more predictable as we all would hit the same errors/problems and we would then be able to set the variables to the proper values for all people. With current situation each user has a different environment and it ends up being hard to figure out what is the concrete offending variable (I remember the old bug 300867 : some people were unable to build webkit-gtk as they were getting "argument list is too long" errors because "something" in their exported variables... but we weren't ever able to know what was the exact offending variable).

My suggestion would then be something like:
- Make PMs unset all variables except a minimum (probably the ones defined in http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-11800011.1 )
- Have an environment.eclass that would allow all of us to set there the variables to the desired values. For example, for XDG_* variable we need to unset the previous random value and set it to a known value under ${T} to prevent sandbox errors due to fallbacks to "real" directories if not defined.

-> The advantage of having the environment.eclass as an eclass is that we can update it when needed without needing to wait for an eapi bump. One problem with that approach is the usual with eclasses, that we would need to inherit that eclass on a lot of packages... but maybe that could be solved if we would finally have a set of "special" eclasses that are inheritted always when eapi >= 6 (or the version that implements this finally) and environment.eclass was one of them

Anyway, this is only a suggestion, I don't know much about PMS and then it's likely there are some drawbacks I haven't noticed due to that :)
Comment 14 Ulrich Müller gentoo-dev 2015-01-05 11:14:18 UTC
If we would introduce an eclass, couldn't it by itself empty the environment?

But I guess this takes us back to comment #3:
> Usually such things are better handled at the ebuild/eclass level, because
> the package manager cannot foresee all eventualities.
Comment 15 Pacho Ramos gentoo-dev 2015-01-05 12:13:01 UTC
In that case, what is the advantage of still allowing to have random and unpredictable variable values "by default"?
Comment 16 Zac Medico gentoo-dev 2015-01-06 07:19:39 UTC
(In reply to Pacho Ramos from comment #15)
> In that case, what is the advantage of still allowing to have random and
> unpredictable variable values "by default"?

You never know what variable might be useful. By leaving it to the ebuild/eclasses to use env -i when necessary, it allows for much more flexibility.
Comment 17 Pacho Ramos gentoo-dev 2015-01-06 14:37:09 UTC
But because of that, we cannot let each run to have a different set of variables around. Then, from my point of view, would be much more predictable to start with an empty environment + some variables that need to be set always (I guess the usual PATHs and other variables listed as "defined" in http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-11800011.1 ). But ebuilds shouldn't rely on the other variables because they will be set to different values depending on the setup
Comment 18 Zac Medico gentoo-dev 2015-01-06 19:09:55 UTC
(In reply to Pacho Ramos from comment #17)
> But because of that, we cannot let each run to have a different set of
> variables around. Then, from my point of view, would be much more
> predictable to start with an empty environment + some variables that need to
> be set always (I guess the usual PATHs and other variables listed as
> "defined" in http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-11800011.1 ).

Why not do this with env -i and add "some variables that need to be set" via env arguments?

> But
> ebuilds shouldn't rely on the other variables because they will be set to
> different values depending on the setup

If you want to do that, use env -i to call emerge. That way, it's still possible to pass in special variables that may be needed, such as for SSH_AUTH_SOCK for live ebuilds that need to fetch sources via ssh.
Comment 19 Pacho Ramos gentoo-dev 2015-01-06 19:35:11 UTC
(In reply to Zac Medico from comment #18)
> (In reply to Pacho Ramos from comment #17)
[...] 
> Why not do this with env -i and add "some variables that need to be set" via
> env arguments?

I am not against that, maybe I misunderstood something sorry.

The point I am trying to explain is that, if PM doesn't clean the environment, each ebuild will behave differently depending on:
- It manually cleaning the environment
- It inheritting an eclass doing that work
- ...

An example I have seen some times: some package tests rely differently depending on DISPLAY being set or not, then:
- If user/developer tends to run them from an xterminal test will work ok
- If user/developer run emerge from a console they will die

In other cases I have also seen some tests opening random windows while I am doing anything because they find a DISPLAY and they use it. 

And there are more different examples depending on each variable, for example the DBUS_SESSION_BUS_ADDRESS has different effect depending on each package/test, on it being set to a wrong value or... 

Then, I would stop letting ebuilds to rely on that variables being set to unknown values and, instead, have them dropped *or* set to known safe values (for DISPLAY and DBUS_SESSION_BUS_ADDRESS they should be unset, for XDG_* they need to point to ${T} to prevent sandbox errors).

Well, re-reading all the thread again I am suggesting nearly the same as comment #4. Personally, I see the proposal of PM cleaning environment + 1 eclass that is inheritted always (to set known variables to proper values) as the one with more "prons". For example for bug 534582 => we now need to go to every single reverse dep to manually clean environment and set XDG_ to their proper values.

And that is only one example for the XDG_ variables, there are multiple more examples involving other variables depending on their values changing on every setup :/
Comment 20 Pacho Ramos gentoo-dev 2015-01-06 19:40:38 UTC
(In reply to Zac Medico from comment #18)
[...]
> If you want to do that, use env -i to call emerge. That way, it's still
> possible to pass in special variables that may be needed, such as for
> SSH_AUTH_SOCK for live ebuilds that need to fetch sources via ssh.

Wouldn't be possible to get that known "locally set" variables exported by that eclass (for example having them in a specified place at /etc and then the eclass taking care to pass its values to the build? That would cover this "feature" too :|
Comment 21 Zac Medico gentoo-dev 2015-01-06 19:56:46 UTC
(In reply to Pacho Ramos from comment #19)
> The point I am trying to explain is that, if PM doesn't clean the
> environment, each ebuild will behave differently depending on:
> - It manually cleaning the environment
> - It inheritting an eclass doing that work
> - ...

That's a result of naive ebuild/eclass writing. These kinds of problems are easily solved by applying env -i liberally.

> An example I have seen some times: some package tests rely differently
> depending on DISPLAY being set or not, then:
> - If user/developer tends to run them from an xterminal test will work ok
> - If user/developer run emerge from a console they will die
> 
> In other cases I have also seen some tests opening random windows while I am
> doing anything because they find a DISPLAY and they use it. 
> 
> And there are more different examples depending on each variable, for
> example the DBUS_SESSION_BUS_ADDRESS has different effect depending on each
> package/test, on it being set to a wrong value or... 
> 
> Then, I would stop letting ebuilds to rely on that variables being set to
> unknown values and, instead, have them dropped *or* set to known safe values
> (for DISPLAY and DBUS_SESSION_BUS_ADDRESS they should be unset, for XDG_*
> they need to point to ${T} to prevent sandbox errors).

There's no one-size-fits-all solution. So ebuilds/eclasses need to apply env -i when appropriate.

> Well, re-reading all the thread again I am suggesting nearly the same as
> comment #4. Personally, I see the proposal of PM cleaning environment + 1
> eclass that is inheritted always (to set known variables to proper values)
> as the one with more "prons". For example for bug 534582 => we now need to
> go to every single reverse dep to manually clean environment and set XDG_ to
> their proper values.
> 
> And that is only one example for the XDG_ variables, there are multiple more
> examples involving other variables depending on their values changing on
> every setup :/

And as always, the problem is naive ebuild/eclass writing.

(In reply to Pacho Ramos from comment #20)
> (In reply to Zac Medico from comment #18)
> [...]
> > If you want to do that, use env -i to call emerge. That way, it's still
> > possible to pass in special variables that may be needed, such as for
> > SSH_AUTH_SOCK for live ebuilds that need to fetch sources via ssh.
> 
> Wouldn't be possible to get that known "locally set" variables exported by
> that eclass (for example having them in a specified place at /etc and then
> the eclass taking care to pass its values to the build? That would cover
> this "feature" too :|

I think using env -i is just as good, maybe better because the package manager doesn't have to get involved. Involving the package manager adds an extra layer of complexity.
Comment 22 Mike Gilbert gentoo-dev 2015-01-06 20:02:09 UTC
(In reply to Zac Medico from comment #21)
> I think using env -i is just as good, maybe better because the package
> manager doesn't have to get involved. Involving the package manager adds an
> extra layer of complexity.

How does one apply env -i to a bash function call (like emake)?
Comment 23 Ciaran McCreesh 2015-01-06 20:03:18 UTC
What's that, Timmy? Your Ruby packages won't build unless you have twenty three obscure environment variables from the global environment that change between Gems releases set?
Comment 24 Zac Medico gentoo-dev 2015-01-06 20:14:24 UTC
(In reply to Mike Gilbert from comment #22)
> (In reply to Zac Medico from comment #21)
> > I think using env -i is just as good, maybe better because the package
> > manager doesn't have to get involved. Involving the package manager adds an
> > extra layer of complexity.
> 
> How does one apply env -i to a bash function call (like emake)?

Here's a way to do it with emake:

   MAKE="env -i ${MAKE}" emake

For econf, you'd have to create a fake configure script that wraps the real configure script.

Neither of these look very appealing, so perhaps we should add some built-in environment filtering support to functions like these, so that they apply env -i internally when desired.
Comment 25 Ciaran McCreesh 2015-01-06 20:20:15 UTC
(In reply to Zac Medico from comment #24)
>    MAKE="env -i ${MAKE}" emake

Recursive?
Comment 26 Zac Medico gentoo-dev 2015-01-06 20:22:42 UTC
(In reply to Ciaran McCreesh from comment #25)
> (In reply to Zac Medico from comment #24)
> >    MAKE="env -i ${MAKE}" emake
> 
> Recursive?

It will work, but obviously it's not very appealing. I think we should build environment filtering support into our helpers. This also has the advantage that it prevents *profile* variables from interfering with the build!
Comment 27 Reto Gantenbein (ganto) 2015-01-06 23:00:26 UTC
Arriving with the experience of debugging #506766, my opinion is that it would much better to generally clean the environment and only allow clearly defined variables (similar to sudo or ssh) to enter the build setup. This would be my expected behaviour of portage.

As it can be seen in the above bug report, it's totally unpredictable what environment variables a build system might use in what (broken) way. Of course this doesn't speak so much for the individual build system, however I think portage should use a more isolated build environment so that the build process is better repeatable and the users can be protected from such undefined behaviour.

Without my digging, I don't think, that the mentioned bug would ever been resolved. Of course this was a very individual case but from a naive gentoo user's point of view, I can't see, why this was my fault (as it was mentioned in the report). A random undocumented user configuration, even when it's the root user, definitely shouldn't influence the build process in such an interruptive way.
Comment 28 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-01-06 23:27:18 UTC
Look at the other side -- some tools simply need passing some environment variables. Think of distcc, for example. We don't want to add exclusions to the PMS every time we hit something.
Comment 29 Gilles Dartiguelongue gentoo-dev 2015-01-06 23:33:43 UTC
even though I am a proponent of the eclass camp, I must admit that we would probably be better off if we had a clean env with a whitelisted set of variables added. This whitelist may contain only what is actually being used by the package manager.

Not sure if it would need any kinds of extension mechanism as long as PM reminds env across phases like it does nowadays.
Comment 30 Pacho Ramos gentoo-dev 2015-01-07 09:40:02 UTC
(In reply to Zac Medico from comment #21)
[...]
> I think using env -i is just as good, maybe better because the package
> manager doesn't have to get involved. Involving the package manager adds an
> extra layer of complexity.

I don't see how it can be better as we would still need to add "env -i" + setting all the needed variables in tons of different ebuilds and eclasses... and also change ebuilds to use that eclasses.

(In reply to Michał Górny from comment #28)
> Look at the other side -- some tools simply need passing some environment
> variables. Think of distcc, for example. We don't want to add exclusions to
> the PMS every time we hit something.

Couldn't that be done with that general "environment.eclass" that could be inheritted always in a newer eapi and, as it's still an "eclass" (even being "special" as is inheritted always) allow us to modify it do add new environment variables?
Comment 31 Zac Medico gentoo-dev 2015-01-07 10:21:55 UTC
(In reply to Pacho Ramos from comment #30)
> (In reply to Zac Medico from comment #21)
> [...]
> > I think using env -i is just as good, maybe better because the package
> > manager doesn't have to get involved. Involving the package manager adds an
> > extra layer of complexity.
> 
> I don't see how it can be better as we would still need to add "env -i" +
> setting all the needed variables in tons of different ebuilds and
> eclasses... and also change ebuilds to use that eclasses.

Your proposed solution doesn't account for possible interference from variables exported by the profile or config files such as make.conf, though. If we integrate environment filtering into the ebuild helpers, then we have a solid solution. If you're concerned about code duplication, then you should use eclasses for code sharing.
Comment 32 Pacho Ramos gentoo-dev 2015-01-07 10:36:52 UTC
Is not possible to make PM to load all the variables from profiles and the defined config files after cleaning the environment? I guess the problem is that it's relying on them being set in previous environment and not explicitly loading them? :/
Comment 33 Zac Medico gentoo-dev 2015-01-07 17:23:11 UTC
(In reply to Pacho Ramos from comment #32)
> Is not possible to make PM to load all the variables from profiles and the
> defined config files after cleaning the environment?

The PM can start with an clean environment, then include all the variables from the profiles and config files. However, as long as those variables are exported, they pose a risk of interference with the build system. This is why I have suggested that ebuild helpers filter the environment, so that calls to the underlying build system do not necessarily see any exported variables that you do not want them to see.

> I guess the problem is
> that it's relying on them being set in previous environment and not
> explicitly loading them? :/

No, it's nothing like that. It's actually very easy for the PM to control what variables are exported. However, there's no guarantee how the underlying build system will behave if it sees those exported variables.
Comment 34 Ulrich Müller gentoo-dev 2016-06-20 21:07:48 UTC
If there is consensus that the course of action should be what I have outlined in comment 12, then I'll put this onto the roadmap for EAPI 7.

That is, add the following variables to the blacklist:
XDG_CACHE_HOME, XDG_CONFIG_HOME, XDG_DATA_HOME, XDG_RUNTIME_DIR
Comment 35 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-06-21 05:42:07 UTC
(In reply to Ulrich Müller from comment #34)
> If there is consensus that the course of action should be what I have
> outlined in comment 12, then I'll put this onto the roadmap for EAPI 7.
> 
> That is, add the following variables to the blacklist:
> XDG_CACHE_HOME, XDG_CONFIG_HOME, XDG_DATA_HOME, XDG_RUNTIME_DIR

There is no consensus. This is fixing a specific issue that we noticed long time ago and that has grown to enormous size today in some undefined future, with no lesson taken for the future.

So in a few months time, we're going to see another major problem like this, and we're going to discuss it all, create another eclass, then add three variables in EAPI 8 with no lesson taken...


What we should do instead is scrub *all* environment variables, except for PM-defined special variables, contents of make.defaults, variables explicitly set by configuration files and explicitly listed pass-through variables. We also should add the list of explicit pass-through envvars to profiles, so developers can easily update that as needed to make eclasses/quirks function.

Alternatively, extend the blacklist with a profile-defined variable. But still, that would be constantly chasing any possible interferences.
Comment 36 Ulrich Müller gentoo-dev 2016-06-21 06:09:43 UTC
(In reply to Michał Górny from comment #35)
> There is no consensus.

Sure, we can make a mountain out of a molehill and continue discussing this for another two years, instead of simply fixing the issue at hand (which is clearly defined in the Summary).
Comment 37 Pacho Ramos gentoo-dev 2016-06-21 19:56:08 UTC
This is not WORKFORME for my case (and I doubt from other gnome team members that are now suffering issues like bug 567192 caused by unproper variables being inheritted and failing in some random ways)

Of course I prefer the mgorny approach of cleaning all environment to prevent errors like this... but if that cannot be done (I think there were another bug for that also stalled for a long time) we NEED at least to mimic xdg.eclass behavior to not need to randomly use it when someone catches an issue related with this concrete variables
Comment 38 Brian Dolbec gentoo-dev 2016-06-21 20:12:00 UTC
As I recall Brian designed pkgcore with a whitelist system rather than the blacklist system currently used by portage.

I think it would make sense to update pms to require a whitelist system.  That would fix most of these types of issues.  Albeit, there would be some currently semi-auto-magic behavior that would have to be fixed in some systems.  As I recall there are occasional pkgs that pkgcore fails to build and install correctly due to some variables not being whitelisted.
Comment 39 Ulrich Müller gentoo-dev 2016-06-21 21:27:17 UTC
(In reply to Brian Dolbec from comment #38)
> As I recall Brian designed pkgcore with a whitelist system rather than the
> blacklist system currently used by portage.
> 
> I think it would make sense to update pms to require a whitelist system. 
> That would fix most of these types of issues.  Albeit, there would be some
> currently semi-auto-magic behavior that would have to be fixed in some
> systems.  As I recall there are occasional pkgs that pkgcore fails to build
> and install correctly due to some variables not being whitelisted.

It should be a blacklist, because a whitelist has several problems.

First, currently all variables are being passed, so any issues with that should be visible now, so we should have an approximate picture where the problems are. Whereas we don't have any idea what problems a complete blocking of the environment would cause.

Second, and more importantly, blacklists can be stacked. So there could be a global blacklist in the profile, and in addition some variables could be blocked on the ebuild level, if they cause problems for one package only. OTOH, a whitelist must necessarily be global, and there is no way to whitelist additional things for one ebuild or eclass. I fear that such a global whitelist would soon grow to a large and unmaintainable mess. (For example, it would have to contain most of the variables defined in /etc/env.d/.)

The blacklist could be defined in a variable like UNSET_VARS in make.defaults. Presumably, only a new EAPI, but no profile EAPI bump would be necessary.
Comment 40 Ulrich Müller gentoo-dev 2016-10-30 18:12:41 UTC
*** Bug 598547 has been marked as a duplicate of this bug. ***
Comment 41 Ulrich Müller gentoo-dev 2016-10-30 18:55:42 UTC
Copied from bug 598547:

Michał Górny 2016-10-30 16:32:23 UTC
Split from bug #499288. The idea is to have a variable specifying blacklist of environment variables for profiles. The variable would be stacked, and the resulting value would be used to unset environment variables that are known to break stuff, such as XDG_* or DISPLAY.
Comment 42 Pacho Ramos gentoo-dev 2016-10-31 09:24:15 UTC
For the concrete case of XDG_ vars... I am not sure if it is enough to simply unset the vars, but also to export them to the proper places for not having sandbox issues (bug 444568 and the thing xdg.eclass is doing)
Comment 43 Ulrich Müller gentoo-dev 2016-10-31 21:18:53 UTC
(In reply to Pacho Ramos from comment #42)
> For the concrete case of XDG_ vars... I am not sure if it is enough to
> simply unset the vars, but also to export them to the proper places for not
> having sandbox issues (bug 444568 and the thing xdg.eclass is doing)

Couldn't that part be handled in an eclass?
Comment 44 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-10-31 22:16:06 UTC
(In reply to Pacho Ramos from comment #42)
> For the concrete case of XDG_ vars... I am not sure if it is enough to
> simply unset the vars, but also to export them to the proper places for not
> having sandbox issues (bug 444568 and the thing xdg.eclass is doing)

What is the exact issue? Libraries not respecting HOME and querying passwd instead?
Comment 45 Pacho Ramos gentoo-dev 2016-11-01 10:00:32 UTC
sandbox violations due to the fallback to /root/. when nothing is set
Comment 46 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-11-01 12:25:41 UTC
(In reply to Pacho Ramos from comment #45)
> sandbox violations due to the fallback to /root/. when nothing is set

That doesn't answer my question. Where does it get /root from?
Comment 47 Pacho Ramos gentoo-dev 2016-11-08 10:34:31 UTC
I was sure this was explained in a bug but I could not find it. It is:
https://bugs.gentoo.org/show_bug.cgi?id=444568#c5

It depends on the packages, but usually they tend to create files on ~/ or even / when the variables are not set a lot. That is the reason we ensure the variables are exported like XDG spec says:
https://bugs.gentoo.org/show_bug.cgi?id=444568#c0

and point them to writable places by portage
Comment 48 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-11-08 11:45:52 UTC
The spec clearly says that if the variables are empty or unset, the applications are supposed to use defaults equal to $HOME subdirectories. So if anything doesn't do that, we should really report a bug instead of working it around. Especially that as you point out, a few common libraries are responsible for this anyway.
Comment 49 Pacho Ramos gentoo-dev 2016-11-16 15:43:29 UTC
Yeah, I guess we could force the filtering from PMS and rely on the eclass for the remaining broken packages (until upstreams care :/). I am not sure of other members of gnome or gstreamer teams (in this case for dev-lang/orc, that looks to be the most relevant case of package failing when none is set) will have more "updated" information about this issue.
Comment 50 Ulrich Müller gentoo-dev 2017-09-09 11:01:21 UTC
*** Bug 567474 has been marked as a duplicate of this bug. ***
Comment 51 Pacho Ramos gentoo-dev 2017-11-05 17:27:57 UTC
It seems the one about unsetting DISPLAY was closed as a dupe to be handled here (updating summary to find the bug more easily)
Comment 52 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-11-07 16:55:41 UTC
Ok, so here's my idea. As I see it, it's easy to implement and as such could be suitable for EAPI 7 still, unless you believe we need to discuss it till death without actually solving any problem.


Let's add ENV_BLACKLIST variable that can be set in make.profile. When processing an EAPI 7 package, the package manager builds a blacklist from ENV_BLACKLIST contents.

The blacklist is constructed by iterating over space-separated strings in the variable, so that:

- if a string does not start with a hyphen ('-'), it is interpreted as a variable fnmatch pattern, and all currently set variables matching it are added to the blacklist,

- if a string starts with a hyphen ('-'), it is stripped and the remainder is interpreted as a variable fnmatch pattern, and all currently set variables match it are removed from the blacklist.

After constructing the blacklist, the package manager guarantees that all variables listed in it will have their values unset.


Examples:

ENV_BLACKLIST=""
  -> full pass-through allowed (but see below)

ENV_BLACKLIST="DESKTOP XDG_*"
  -> strip 'DESKTOP' and everything starting with 'XDG_'
     (though I'd discourage wildcards like this)

ENV_BLACKLIST="* -FOO -BAR"
  -> strip everything except for 'FOO' and 'BAR'


Most notably, this has the following implications:

1. If ENV_BLACKLIST is unset (old profiles, custom profiles), the behavior doesn't change.

2. The spec only requires blacklisting specific variables. The remaining variables can be passed through via blacklist/whitelist as PM logic and/or configuration permits which allows what different PMs do.

3. We start with blacklist which is easier to implement without breaking stuff. We may eventually switch to whitelist as we see fit.

4. I think we can do this without bumping profile EAPI since the extra variable does not affect anything but ebuilds with the new EAPI.

5. fnmatch patterns aren't really necessary but they provide the '*' for whitelist variant, and are cleaner than special casing '*'.
Comment 53 Pacho Ramos gentoo-dev 2017-11-07 18:29:17 UTC
It looks ok to me :)
Comment 54 Ulrich Müller gentoo-dev 2017-11-09 17:12:31 UTC
(In reply to Michał Górny from comment #52)
> 5. fnmatch patterns aren't really necessary but they provide the '*' for
> whitelist variant, and are cleaner than special casing '*'.

I strongly disagree about this part. There should be a blacklist only, for the reasons stated in comment #39.
Comment 55 Larry the Git Cow gentoo-dev 2018-03-11 11:44:01 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/proj/portage.git/commit/?id=a5e02c92fd72aad6eb9031cdc04f634543ebdd15

commit a5e02c92fd72aad6eb9031cdc04f634543ebdd15
Author:     Michał Górny <mgorny@gentoo.org>
AuthorDate: 2018-02-21 09:54:18 +0000
Commit:     Michał Górny <mgorny@gentoo.org>
CommitDate: 2018-03-11 11:43:41 +0000

    Support ENV_UNSET for EAPI 7
    
    Bug: https://bugs.gentoo.org/499288

 bin/eapi.sh            | 4 ++++
 bin/ebuild.sh          | 6 ++++++
 pym/_emerge/actions.py | 4 ++--
 pym/portage/const.py   | 3 ++-
 4 files changed, 14 insertions(+), 3 deletions(-)}
Comment 56 Larry the Git Cow gentoo-dev 2018-04-30 22:14:13 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/proj/pms.git/commit/?id=7e94b3912fff029b0201ec803b15c69146ac84bb

commit 7e94b3912fff029b0201ec803b15c69146ac84bb
Author:     Ulrich Müller <ulm@gentoo.org>
AuthorDate: 2017-11-10 13:51:41 +0000
Commit:     Ulrich Müller <ulm@gentoo.org>
CommitDate: 2018-03-31 15:30:43 +0000

    EAPI 7 has ENV_UNSET.
    
    Thanks to mgorny for providing the initial wording.
    
    Bug: https://bugs.gentoo.org/499288

 eapi-differences.tex  |  4 ++++
 ebuild-env-vars.tex   |  2 ++
 profile-variables.tex | 23 +++++++++++++++++++++++
 3 files changed, 29 insertions(+)}