Bug 595028 – sys-apps/portage runs pkg_preinst and pkg_postinst from python sitedir

• Product: Portage Development
• Status: RESOLVED FIXED

[Description Mike Gilbert 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 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 2016-09-24 15:16:06 UTC]

The current behavior is a result of these lines in ebuild.sh:

# 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 2016-09-24 19:48:00 UTC]

It has to be a trusted directory for python import security (bug 239560).

[Comment 4 Mike Gilbert 2016-09-24 22:20:40 UTC]

Maybe create an empty directory for it then?

[Comment 5 Zac Medico 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 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 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 8 Zac Medico 2016-09-25 01:52:50 UTC]

Patch sent for review:

https://archives.gentoo.org/gentoo-portage-dev/message/61e44b4b2e62dd9e4449aac504219447
https://github.com/gentoo/portage/pull/54

[Comment 9 Zac Medico 2016-09-26 17:22:06 UTC]

In the master branch:

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

[Comment 10 Zac Medico 2017-02-10 18:51:17 UTC]

Fixed in portage-2.3.3.