Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 595028 - sys-apps/portage runs pkg_preinst and pkg_postinst from python sitedir
Summary: sys-apps/portage runs pkg_preinst and pkg_postinst from python sitedir
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Ebuild Support (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
Keywords: InVCS
Depends on: CVE-2008-4394
Blocks: 604854
  Show dependency tree
Reported: 2016-09-24 14:42 UTC by Mike Gilbert
Modified: 2017-02-10 18:51 UTC (History)
0 users

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


Note You need to log in before you can comment on or make changes to this bug.
Description Mike Gilbert gentoo-dev 2016-09-24 14:42:02 UTC
The initial working directory for the pkg_preinst and pkg_postinst functions is somehow set to /usr/lib/pythonX.Y/site-packages in recent versions of portage. This causes strange issues when python is invoked from within the pkg function. 

For example, see bug 574002. Here, the working directory in pkg_preinst is /usr/lib64/python2.7/site-packages. This results in this path being added to sys.path when invoking python3, which causes some very odd behavior in dev-python/packagin.

PMS does not specify any particular behavior here, but it would be nice if portage used a more sensible default to avoid random bug reports that are difficult to diagnose. Perhaps this could also be standardize in a future EAPI.

Can we change the default working directory to something like WORKDIR? Or maybe ROOT?
Comment 1 Mike Gilbert gentoo-dev 2016-09-24 14:51:42 UTC
I see that WORKDIR is not valid in pkg functions. Maybe ROOT or EROOT would work instead.
Comment 2 Mike Gilbert gentoo-dev 2016-09-24 15:16:06 UTC
The current behavior is a result of these lines in

# Ensure that $PWD is sane whenever possible, to protect against
# exploitation of insecure search path for python -c in ebuilds.
# See bug #239560 and bug #469338.
cd "${PORTAGE_PYM_PATH}" || \
    die "PORTAGE_PYM_PATH does not exist: '${PORTAGE_PYM_PATH}'"

Since we don't change the working directory before invoking the pkg_* functions, we end up starting them in PORTAGE_PYM_DIR.
Comment 3 Zac Medico gentoo-dev 2016-09-24 19:48:00 UTC
It has to be a trusted directory for python import security (bug 239560).
Comment 4 Mike Gilbert gentoo-dev 2016-09-24 22:20:40 UTC
Maybe create an empty directory for it then?
Comment 5 Zac Medico gentoo-dev 2016-09-25 00:25:37 UTC
I think $HOME makes sense. It the context of ebuilds, portage creates a temporary $HOME which is an empty directory located at $PORTAGE_BUILDDIR/homedir (it's a sibling of standard directories including $WORKDIR, $T, and $D).
Comment 6 Zac Medico gentoo-dev 2016-09-25 00:35:20 UTC
Since portage's __save_ebuild_env filters the HOME variable, we can assume that at the beginning of each phase function, it will have the $PORTAGE_BUILDDIR/homedir value that is set by the doebuild_environment function.
Comment 7 Zac Medico gentoo-dev 2016-09-25 00:51:14 UTC
These are the only commands where $HOME is not guaranteed to be valid:

_doebuild_commands_without_builddir = (
	'clean', 'cleanrm', 'depend', 'digest',
	'fetch', 'fetchall', 'help', 'manifest'

For all other commands, $HOME is guaranteed to be created by the prepare_build_dirs function.
Comment 10 Zac Medico gentoo-dev 2017-02-10 18:51:17 UTC
Fixed in portage-2.3.3.