Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 814857 - sys-apps/portage: doexe preserves all xattrs, including ACL, from source file
Summary: sys-apps/portage: doexe preserves all xattrs, including ACL, from source file
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on: 815196 815871 816291
Blocks: 193766 563798
  Show dependency tree
 
Reported: 2021-09-25 22:38 UTC by Piotr Karbowski (RETIRED)
Modified: 2023-11-27 13:50 UTC (History)
3 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 Piotr Karbowski (RETIRED) gentoo-dev 2021-09-25 22:38:08 UTC
All portage releases up to now have a unwanted behavior of preserving any xattrs from source file when running 'doexe' like app-arch/tar does with /etc/rmt.

This means that the ebuild have no control over the actual permissions that are applied to files installed with doexe and depends on the xattrs that were present in ::gentoo tree during the build time, resulting in them being redistributed with binary packages.

My workflow heavily depends on ACL to allow my regular user to add, edit and commit ebuilds in /var/db/repos, for convenience I use Posix ACL for that, instead of jumping to root or portage users and making commits there.

    setfacl --recursive --default -m user:piotr:rwx,user:portage:rwx /var/db/repos/

Those settings ensure that regardless of who's the owner, 'piotr', or 'portage', both of said users can access those files.

What it also means now that those attributes are copied when doexe is used, so in this case both portage and piotr users can edit /etc/rmt on *any* system that installed bin packages built on those machines.

The reason for that is because ebuild-helpers/doexe uses ebuild-helpers/xattr/install that spawns /usr/bin/install-xattr which is the very reason for this bug.

This is not the case with ebuild-helper/newbin, since it uses 'cp' which obeys umask settings, keeping the exec bit if source file had one.

The problem currently surfaces on anything copied with doexe from $FILESDIR that have any xattrs, however it seems much more serious when one take into consolidation that we will be distributing absolute any xattrs that could be set by build system or part of the source tarball with *anything* that runs 'install' helper which is [doins, doexe, doman, doinfo, dobin, dodoc, dolib, domo]

I am not entirely sure what's the rationale for having 'install' helper that supports xattrs in the first place, is it also used when merging $D into rootfs perhaps?
Comment 1 Piotr Karbowski (RETIRED) gentoo-dev 2021-09-25 22:51:16 UTC
Introduced with https://bugs.gentoo.org/465000
Comment 2 Piotr Karbowski (RETIRED) gentoo-dev 2021-09-25 23:01:09 UTC
extending the default PORTAGE_XATTR_EXCLUDE with system.posix_acl_access and trusted.SGI_ACL_FILE might be the best way to hnadle it.
Comment 3 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2021-09-26 06:21:25 UTC
I think the simplest solution would be to actually copy (or hardlink) files into a temporary FILESDIR, resetting their mode and so on.  This shouldn't be a big deal since the files are supposed to be small.

I'm afraid though that a similar problem applies to DISTDIR and copying everything there is not really an option.
Comment 4 Piotr Karbowski (RETIRED) gentoo-dev 2021-09-26 09:52:53 UTC
+1 for the changes you propose in your pull request.
Comment 5 Larry the Git Cow gentoo-dev 2021-09-27 06:55:29 UTC
The bug has been referenced in the following commit(s):

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

commit 2fa008aae8571d525af1f5ca7cf4cce90d835826
Author:     Michał Górny <mgorny@gentoo.org>
AuthorDate: 2021-09-26 07:07:32 +0000
Commit:     Michał Górny <mgorny@gentoo.org>
CommitDate: 2021-09-26 10:19:39 +0000

    Copy files/* into the work tree instead of symlinking it
    
    Symlinking FILESDIR into the work tree has the unintended consequence
    of preserving all original file metadata, including system-specific ACLs
    and so on.  When these files are installed, this could lead to
    unintentionally copying this metadata to the system and/or binary
    packages.
    
    Let's copy all files instead and drop metadata in the process.  Since
    FILESDIR is expected to be small by design, this shouldn't cause any
    major trouble.  It is also easier and less likely to cause regressions
    than making sure stuff is not preserved when installing.
    
    Unfortunately, a similar problem applies to DISTDIR.  However,
    installing files from DISTDIR is rarer than from FILESDIR, so I guess
    we'll cross that bridge when we get to it.
    
    Bug: https://bugs.gentoo.org/814857
    Signed-off-by: Michał Górny <mgorny@gentoo.org>

 bin/phase-functions.sh                           |  2 +-
 lib/portage/package/ebuild/prepare_build_dirs.py | 19 +++++++++----------
 2 files changed, 10 insertions(+), 11 deletions(-)
Comment 6 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-04-14 03:11:42 UTC
Final fix was, I think:

From 773ba1701f94bdd46086d294efcf97985b67841d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= <mgorny@gentoo.org>
Date: Tue, 28 Sep 2021 13:23:16 +0200
Subject: [PATCH] Attempt to fix creating FILESDIR properly
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Since we perform a mode fixup on FILESDIR anyway, just let copytree()
create it.  This should finally fix all the problems: have the directory
created without errors and work with Python < 3.8.

Signed-off-by: Michał Górny <mgorny@gentoo.org>
---
 lib/portage/package/ebuild/prepare_build_dirs.py | 1 -
 1 file changed, 1 deletion(-)

Still need to handle DISTDIR somehow.
Comment 7 James Le Cuirot gentoo-dev 2023-11-26 18:00:42 UTC
The state of this is unclear. It reads like FILESDIR is fixed, but the fix was reverted, so we're back to where we were originally.