Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC
Bug 705178 - sys-apps/portage: failed to create hard link to SUID binary in LXC user namespace container
Summary: sys-apps/portage: failed to create hard link to SUID binary in LXC user names...
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: Normal normal (vote)
Assignee: Portage team
URL: https://github.com/lxc/lxc/issues/669
Whiteboard:
Keywords:
Depends on: 421099
Blocks:
  Show dependency tree
 
Reported: 2020-01-11 19:57 UTC by Fedja Beader
Modified: 2020-01-20 19:36 UTC (History)
1 user (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 Fedja Beader 2020-01-11 19:57:50 UTC
excerp of build log:

>>> Completed installing mail-mta/nullmailer-2.2 into /tmp/portage/mail-mta/nullmailer-2.2/image                                                                                 

 * Final size of build directory: 3836 KiB (3.7 MiB)
 * Final size of installed tree:   716 KiB

 * system executables owned by nonzero uid:
 *   /usr/bin/mailq
 *   /usr/sbin/nullmailer-queue
strip: x86_64-pc-linux-gnu-strip --strip-unneeded -N __gentoo_check_ldflags__ -R .comment -R .GCC.command.line -R .note.gnu.gold-version
   /usr/libexec/nullmailer/smtp
   /usr/sbin/nullmailer-queue
   /usr/libexec/nullmailer/qmqp
ln: failed to create hard link '107813859_stripped' => '/tmp/portage/mail-mta/nullmailer-2.2/image/usr/sbin/nullmailer-queue': Permission denied
   /usr/sbin/nullmailer-send
 * ERROR: mail-mta/nullmailer-2.2::gentoo failed:


Forum posts from years ago by someone else (and zmedico's recent response): https://forums.gentoo.org/viewtopic-p-7824072.html


Would allowing the creation of hard links to suid files allow the container to hard-link to some visible host-root-owned file and set it to suid? Perhaps even overwriting it with some other contents?

Which capability controls this privilege?



sys-process/fcron has the same issue.
Comment 1 Zac Medico gentoo-dev 2020-01-11 23:06:01 UTC
This is the Portage code that triggers it, now located in bin/estrip:

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

commit 74b7c9d452c97a948852416e1456a3117deec2dc
Author:     Zac Medico <zmedico@gentoo.org>
AuthorDate: 2012-11-04 18:51:20 -0800
Commit:     Zac Medico <zmedico@gentoo.org>
CommitDate: 2012-11-04 18:51:20 -0800

    prepstrip: account for new inode created by strip
    
    Since strip creates a new inode, we need to know the initial set of
    inodes in advance, so that we can avoid interference due to trying
    to strip the same (hardlinked) file multiple times in parallel.
    See bug #421099.

 bin/ebuild-helpers/prepstrip | 60 +++++++++++++++++++++++++++++++-------------
 1 file changed, 43 insertions(+), 17 deletions(-)
Comment 2 Zac Medico gentoo-dev 2020-01-11 23:58:18 UTC
(In reply to Fedja Beader from comment #0)
> ln: failed to create hard link '107813859_stripped' =>
> '/tmp/portage/mail-mta/nullmailer-2.2/image/usr/sbin/nullmailer-queue':
> Permission denied

The SUID bit would have been set by the *same* root user during src_install, therefore it's nonsensical to deny permission to *same* root user to create a hardlink, though it makes perfect sense within the context of an unprivileged user running under the fs.protected_hardlinks=1 sysctl.

Would permission be allowed for the *same* root user to remove the SUID bit prior to creating the hardlink, and then restore the SUID bit after creating the hardlink? It seems like it should be, since the *same* root user set the SUID bit in the first place.
Comment 3 Zac Medico gentoo-dev 2020-01-12 00:17:06 UTC
(In reply to Zac Medico from comment #2)
> Would permission be allowed for the *same* root user to remove the SUID bit
> prior to creating the hardlink, and then restore the SUID bit after creating
> the hardlink? It seems like it should be, since the *same* root user set the
> SUID bit in the first place.

And if that doesn't work, how about if we chown the file to root:root and then chown it back (to nullmail:nullmail in the case of /usr/sbin/nullmailer-queue) after creating the hardlink?
Comment 4 Fedja Beader 2020-01-15 12:58:28 UTC
(In reply to Zac Medico from comment #2)
> (In reply to Fedja Beader from comment #0)
> > ln: failed to create hard link '107813859_stripped' =>
> > '/tmp/portage/mail-mta/nullmailer-2.2/image/usr/sbin/nullmailer-queue':
> > Permission denied
> 
> The SUID bit would have been set by the *same* root user during src_install,
> therefore it's nonsensical to deny permission to *same* root user to create
> a hardlink, though it makes perfect sense within the context of an
> unprivileged user running under the fs.protected_hardlinks=1 sysctl.
> 
> Would permission be allowed for the *same* root user to remove the SUID bit
> prior to creating the hardlink, and then restore the SUID bit after creating
> the hardlink? It seems like it should be, since the *same* root user set the
> SUID bit in the first place.

Permission is allowed for this, yes:
cd /tmp
touch test1
chown nullmail:nullmail test1
chmod 04644 test1
chmod 00644 test1
ln test1 testln
chmod 04644 test1

result: both test1 and testln are 04644 and owned by nullmail.


I wonder though, what would happen if hardlinks were not used? If simple copies were used, it would result in duplicates on disk, yes? If symlinks were used, it would result in ...? Busybox has used symlinks since forever to achieve the same?
Comment 5 Zac Medico gentoo-dev 2020-01-19 06:01:57 UTC
(In reply to Fedja Beader from comment #4)
> Permission is allowed for this, yes:
> cd /tmp
> touch test1
> chown nullmail:nullmail test1
> chmod 04644 test1
> chmod 00644 test1
> ln test1 testln
> chmod 04644 test1
> 
> result: both test1 and testln are 04644 and owned by nullmail.

So we can circumvent the fs.protected_hardlinks=1 sysctl. That's useful.

> I wonder though, what would happen if hardlinks were not used? If simple
> copies were used, it would result in duplicates on disk, yes? If symlinks
> were used, it would result in ...? Busybox has used symlinks since forever
> to achieve the same?

The hardlinks are very convenient approach, so maybe it's better if we just toggle the suid bit when creating hardlinks.
Comment 6 Zac Medico gentoo-dev 2020-01-19 06:13:55 UTC
We should get details about your filesystem, since it might be possible to circumvent the fs.protected_hardlinks=1 sysctl in the filesystem itself.
Comment 7 Fedja Beader 2020-01-19 10:52:15 UTC
The filesystem on /tmp is tmpfs.

Can the files not be tracked in some structure inside Portage?
Comment 8 Zac Medico gentoo-dev 2020-01-20 05:41:21 UTC
(In reply to Fedja Beader from comment #7)
> The filesystem on /tmp is tmpfs.
> 
> Can the files not be tracked in some structure inside Portage?

We can add a fallback to circumvent the error inside Portage.

However, first we should verify that your kernel is operating correctly.

What's your linux kernel version?

Considering that your root user is capable of removing and then re-adding the SUID bit, it seems like it should have the CAP_FOWNER privilege within the user namespace.

The inode_owner_or_capable function should recognize that your root user has CAP_FOWNER within the current user namespace:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/inode.c?h=cc658db47d6897a8571fb6227f59d1d18151b0b2#n2011

The inode_owner_or_capable function is used in the implementation of the fs.protected_hardlinks sysctl, inside the may_linkat function. This commit from 2015 is supposed to handle it: 

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f2ca379642d7a843be972ea4167abdd3c8c9e5d1
Comment 9 Fedja Beader 2020-01-20 19:36:12 UTC
I have 4.9.24. WIil try the kernel fix.