Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 527380 - dev-lang/perl: /usr/bin/perl being an symlink is a problem for Hardened Gentoo (RBAC-enabled) systems.
Summary: dev-lang/perl: /usr/bin/perl being an symlink is a problem for Hardened Gento...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Hardened (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: The Gentoo Linux Hardened Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-29 21:49 UTC by Piotr Karbowski (RETIRED)
Modified: 2014-12-19 18:53 UTC (History)
2 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 2014-10-29 21:49:33 UTC
At this very moment src_install() of dev-lang/perl removes /usr/bin/perl and replaces it with a symlink to perl<version>.

This turns out to be an issue on RBAC-enabled systems that have an subject for /usr/bin/perl. The RBAC's userspace, gradm, resolves symlinks upon policy loading, meaning if perl happen to be upgraded with RBAC is enabled, the subject will no longer recognize new target of /usr/bin/perl as the /usr/bin/perl subject.

The solution for handling such situations would be to make perl a hardlink instead of a symlink. Both lays in the same dir so it shouldn't be an problem, and git already provide multiple hardlinks.

--- src_install-v50160001.eblit.orig	2014-10-29 22:47:48.947477000 +0100
+++ src_install-v50160001.eblit	2014-10-29 22:48:27.917478686 +0100
@@ -8,8 +8,7 @@
 
 	emake DESTDIR="${D}" install
 
-	rm -f "${ED}"/usr/bin/perl
-	ln -s perl${MY_PV} "${ED}"/usr/bin/perl || die
+	ln -f perl${MY_PV} "${ED}"/usr/bin/perl || die
 
 	if ! tc-is-static-only ; then
 		dolib.so "${ED}"${coredir}/${LIBPERL}



Reproducible: Always
Comment 1 Andreas K. Hüttel archtester gentoo-dev 2014-10-29 22:55:52 UTC
OK, here's a well-defined problem. Not sure what the best solution is.

@hardened: thx for your input / advice
Comment 2 Anthony Basile gentoo-dev 2014-10-29 23:28:21 UTC
(In reply to Piotr Karbowski from comment #0)
> At this very moment src_install() of dev-lang/perl removes /usr/bin/perl and
> replaces it with a symlink to perl<version>.
> 
> This turns out to be an issue on RBAC-enabled systems that have an subject
> for /usr/bin/perl. The RBAC's userspace, gradm, resolves symlinks upon
> policy loading, meaning if perl happen to be upgraded with RBAC is enabled,
> the subject will no longer recognize new target of /usr/bin/perl as the
> /usr/bin/perl subject.

I personally have never had luck upgrading while RBAC is enabled.  Problems arise as the structure of the package changes.  What I have done is either do relearning again which is a pita, or more often just edited the policy file manually.

> 
> The solution for handling such situations would be to make perl a hardlink
> instead of a symlink. Both lays in the same dir so it shouldn't be an
> problem, and git already provide multiple hardlinks.
> 
> --- src_install-v50160001.eblit.orig	2014-10-29 22:47:48.947477000 +0100
> +++ src_install-v50160001.eblit	2014-10-29 22:48:27.917478686 +0100
> @@ -8,8 +8,7 @@
>  
>  	emake DESTDIR="${D}" install
>  
> -	rm -f "${ED}"/usr/bin/perl
> -	ln -s perl${MY_PV} "${ED}"/usr/bin/perl || die
> +	ln -f perl${MY_PV} "${ED}"/usr/bin/perl || die
>  
>  	if ! tc-is-static-only ; then
>  		dolib.so "${ED}"${coredir}/${LIBPERL}

This is a bad idea.  It will fail if you are crossing filesystems and I'm sure that will hit some of our users.

If this is not a production machine, then try editing /etc/grsec/policy and changing instances of /usr/bin/perl to perl5.18.2 and see if that fixes the problem.  If not, do the relearning again and compare your old and new policy files.  The way to deal with this problem is documenation on how to work with RBAC and not changing the perl ebuild.

Let me know and we can add soemthing to the documentation.
Comment 3 Piotr Karbowski (RETIRED) gentoo-dev 2014-10-30 08:16:45 UTC
(In reply to Anthony Basile from comment #2)
> (In reply to Piotr Karbowski from comment #0)
> > At this very moment src_install() of dev-lang/perl removes /usr/bin/perl and
> > replaces it with a symlink to perl<version>.
> > 
> > This turns out to be an issue on RBAC-enabled systems that have an subject
> > for /usr/bin/perl. The RBAC's userspace, gradm, resolves symlinks upon
> > policy loading, meaning if perl happen to be upgraded with RBAC is enabled,
> > the subject will no longer recognize new target of /usr/bin/perl as the
> > /usr/bin/perl subject.
> 
> I personally have never had luck upgrading while RBAC is enabled.  Problems
> arise as the structure of the package changes.  What I have done is either
> do relearning again which is a pita, or more often just edited the policy
> file manually.

Maintaining RBAC-enabled system is challenging but possible. Portage have few if-o-logic for selinux, adding additional few for RBAC will do the trick, but that's another story.

> > 
> > The solution for handling such situations would be to make perl a hardlink
> > instead of a symlink. Both lays in the same dir so it shouldn't be an
> > problem, and git already provide multiple hardlinks.
> > 
> > --- src_install-v50160001.eblit.orig	2014-10-29 22:47:48.947477000 +0100
> > +++ src_install-v50160001.eblit	2014-10-29 22:48:27.917478686 +0100
> > @@ -8,8 +8,7 @@
> >  
> >  	emake DESTDIR="${D}" install
> >  
> > -	rm -f "${ED}"/usr/bin/perl
> > -	ln -s perl${MY_PV} "${ED}"/usr/bin/perl || die
> > +	ln -f perl${MY_PV} "${ED}"/usr/bin/perl || die
> >  
> >  	if ! tc-is-static-only ; then
> >  		dolib.so "${ED}"${coredir}/${LIBPERL}
> 
> This is a bad idea.  It will fail if you are crossing filesystems and I'm
> sure that will hit some of our users.

I am sure that in this particular case hardlink won't harm at all. As both perl and for example perl5.20.1 lives in the same dir, which means they're on the same filesystem. the symlink -> hardlink is a cheap solution, as you preserve the `perl` and `perl<version>` paths regardless, there's no symlink and you did not duplicated files.

GIT already uses such approach, multiple binaries being hardlink in a single directory under /usr/libexec/git-core/ dir:

    piotr@sabre ~ % ls -li /usr/libexec/git-core | sort | tail
    1835730 -rwxr-xr-x 112 root root  1.9M Oct 18 15:39 git-var*
    1835730 -rwxr-xr-x 112 root root  1.9M Oct 18 15:39 git-verify-commit*
    1835730 -rwxr-xr-x 112 root root  1.9M Oct 18 15:39 git-verify-pack*
    1835730 -rwxr-xr-x 112 root root  1.9M Oct 18 15:39 git-verify-tag*
    1835730 -rwxr-xr-x 112 root root  1.9M Oct 18 15:39 git-whatchanged*
    1835730 -rwxr-xr-x 112 root root  1.9M Oct 18 15:39 git-write-tree*

Would you kindly reconsider turning perl symlink into hardlink?

Here's the fixed patch:

--- src_install-v50160001.eblit.orig	2014-10-29 22:47:48.947477000 +0100
+++ src_install-v50160001.eblit	2014-10-29 22:48:27.917478686 +0100
@@ -8,8 +8,7 @@
 
 	emake DESTDIR="${D}" install
 
-	rm -f "${ED}"/usr/bin/perl
-	ln -s perl${MY_PV} "${ED}"/usr/bin/perl || die
+	ln -f "${ED}"/usr/bin/perl${MY_PV} "${ED}"/usr/bin/perl || die
 
 	if ! tc-is-static-only ; then
 		dolib.so "${ED}"${coredir}/${LIBPERL}


And it gets the job done. ;-)

sugoi [SSH] perl # ls -li /usr/bin/perl{,5.20.1}
183623 -rwxr-xr-x 2 root root 11K Oct 30 09:15 /usr/bin/perl*
183623 -rwxr-xr-x 2 root root 11K Oct 30 09:15 /usr/bin/perl5.20.1*

-- Piotr.
Comment 4 Martin Väth 2014-10-30 13:09:40 UTC
(In reply to Piotr Karbowski from comment #3)
> on the same filesystem. the symlink -> hardlink is a cheap solution

... causing headache for binpkg, backups, and other occassions where there is no explicit search for hardlinks.

> GIT already uses such approach

For this reason, git costed me such a lot of redundant storage that I already decided to patched git in my local overlay.
Please do not do this for even more packages.

An independent idea: Since perl is not slotted, which not just rename perl?
Comment 5 Piotr Karbowski (RETIRED) gentoo-dev 2014-10-30 13:29:17 UTC
(In reply to Martin Väth from comment #4)
 > An independent idea: Since perl is not slotted, which not just rename perl?

Works for me, we could, beside rename perl<version> into perl, leave symlink perl<version> -> perl for backward compatibility, at least for few releases with a 'eselect news' entry about it.
Comment 6 Piotr Karbowski (RETIRED) gentoo-dev 2014-12-15 19:07:15 UTC
*friendly bump*
Comment 7 Andreas K. Hüttel archtester gentoo-dev 2014-12-19 18:53:17 UTC
(In reply to Piotr Karbowski from comment #6)
> *friendly bump*

This is fixed in 5.20.1-r4 (where perl5.20.1 is a symlink to perl, not the other way around).