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
OK, here's a well-defined problem. Not sure what the best solution is. @hardened: thx for your input / advice
(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.
(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.
(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?
(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.
*friendly bump*
(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).