Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 816291 - sys-apps/portage: copying files into work tree broken on SELinux systems
Summary: sys-apps/portage: copying files into work tree broken on SELinux systems
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords: REGRESSION
Depends on:
Blocks: 814857
  Show dependency tree
 
Reported: 2021-10-04 21:35 UTC by Kenton Groombridge
Modified: 2022-04-14 03:11 UTC (History)
2 users (show)

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


Attachments
portage-shell-output.log (portage-shell-output.log,1.72 KB, text/x-log)
2021-10-04 22:00 UTC, Kenton Groombridge
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kenton Groombridge gentoo-dev 2021-10-04 21:35:40 UTC
https://gitweb.gentoo.org/proj/portage.git/commit/lib/portage/package/ebuild/prepare_build_dirs.py?id=2fa008aae8571d525af1f5ca7cf4cce90d835826 now copies the files into the working tree instead of symlinking it, but on SELinux systems the current behavior is to also copy the SELinux context, which Portage does not have permissions to, resulting in the following AVC denial:

type=AVC msg=audit(1633382732.180:38575): avc:  denied  { relabelto } for  pid=273559 comm="emerge" name="files" dev="vda3" ino=508333 scontext=staff_u:sysadm_r:portage_t:s0-s0:c0.c1023 tcontext=system_u:object_r:portage_ebuild_t:s0 tclass=dir permissive=0

The proper solution seems to be just to omit copying the SELinux context and opt to use portage_tmp_t instead, but as a workaround we could allow portage_t this access for now.

Reproducible: Always

Steps to Reproduce:
1. Use a Gentoo system with SELinux in enforcing mode.
2. Emerge any package.
3. Observe as portage crashes while setting up the work tree.
Comment 1 Kenton Groombridge gentoo-dev 2021-10-04 21:59:26 UTC
Correction: this only happens with packages that have a files/ directory in their ebuild path.
Comment 2 Kenton Groombridge gentoo-dev 2021-10-04 22:00:03 UTC
Created attachment 743001 [details]
portage-shell-output.log

Shell output of Portage when the crash occurs.
Comment 3 Zac Medico gentoo-dev 2021-10-05 02:27:04 UTC
We can avoid the issue by doing it in bash, similarly to this code in bin/phase-functions.sh which copies the ebuild:

> 			cd "$PORTAGE_BUILDDIR"
> 			if [ ! -d build-info ] ; then
> 				mkdir build-info
> 				cp "$EBUILD" "build-info/$PF.ebuild"
> 			fi
Comment 4 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2021-10-05 06:52:47 UTC
I'm just going to revert to the old behavior.
Comment 5 Larry the Git Cow gentoo-dev 2021-10-05 08:27:30 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=932561e71818222ebb15def5987c8d84c2a18ae8

commit 932561e71818222ebb15def5987c8d84c2a18ae8
Author:     Michał Górny <mgorny@gentoo.org>
AuthorDate: 2021-10-05 07:23:28 +0000
Commit:     Michał Górny <mgorny@gentoo.org>
CommitDate: 2021-10-05 08:27:26 +0000

    sys-apps/portage: Bump to 3.0.28
    
    Closes: https://bugs.gentoo.org/816291
    Signed-off-by: Michał Górny <mgorny@gentoo.org>

 sys-apps/portage/Manifest              |   1 +
 sys-apps/portage/portage-3.0.28.ebuild | 264 +++++++++++++++++++++++++++++++++
 2 files changed, 265 insertions(+)
Comment 6 jospezial 2021-10-05 23:59:17 UTC
Because the revert changed "rm -rf" to "rm -f",
on a package that failed 2 days ago I get today this message:

>>> Emerging (1 of 1) kde-frameworks/extra-cmake-modules-9999::kde
rm: cannot remove '/var/tmp/portage/kde-frameworks/extra-cmake-modules-9999/files': Is a directory
Exception in callback AsynchronousTask._exit_listener_cb(<bound method...7f41f55a1ea0>>)
handle: <Handle AsynchronousTask._exit_listener_cb(<bound method...7f41f55a1ea0>>)>
Traceback (most recent call last):
  File "/usr/lib/python3.10/site-packages/portage/package/ebuild/prepare_build_dirs.py", line 484, in _prepare_fake_filesdir
    link_target = os.readlink(symlink_path)
  File "/usr/lib/python3.10/site-packages/portage/__init__.py", line 282, in __call__
    rval = self._func(*wrapped_args, **wrapped_kwargs)
OSError: [Errno 22] Invalid argument: b'/var/tmp/portage/kde-frameworks/extra-cmake-modules-9999/files'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.10/asyncio/events.py", line 80, in _run
    self._context.run(self._callback, *self._args)
  File "/usr/lib/python3.10/site-packages/_emerge/AsynchronousTask.py", line 210, in _exit_listener_cb
    listener(self)
  File "/usr/lib/python3.10/site-packages/_emerge/EbuildPhase.py", line 187, in _async_start_exit
    self._start_lock()
  File "/usr/lib/python3.10/site-packages/_emerge/EbuildPhase.py", line 210, in _start_lock
    self._start_ebuild()
  File "/usr/lib/python3.10/site-packages/_emerge/EbuildPhase.py", line 248, in _start_ebuild
    _prepare_fake_filesdir(self.settings)
  File "/usr/lib/python3.10/site-packages/portage/package/ebuild/prepare_build_dirs.py", line 486, in _prepare_fake_filesdir
    os.symlink(real_filesdir, symlink_path)
  File "/usr/lib/python3.10/site-packages/portage/__init__.py", line 282, in __call__
    rval = self._func(*wrapped_args, **wrapped_kwargs)
FileExistsError: [Errno 17] File exists: b'/var/db/repos/kde/kde-frameworks/extra-cmake-modules/files' -> b'/var/tmp/portage/kde-frameworks/extra-cmake-modules-9999/files'
Beendet

So I have to delete the directory by hand.