As part of my testing regimen finding existing versions that will need to be nuked prior to future perl releases entering tree, webdavcgi-0.8.3 got installed ( with USE=suid, the default as per IUSE ) After that point, "emerge -C webdavcgi" ceased to operate, and instead, died without explanation ( or even error messages ) Similarly, "emerge --depclean" bailed pretty early in its removal as soon as webdavcgi became a removal target. Oddly, the errors for webdavcgi were nowhere to be found in any webdavcgi removal log... Instead, they appear in the log for the package that was being removed before it: cat /var/log/portage-build/build/xfce-base/libxfce4ui-4.13.4:20180117-005033.log * Updating icons cache ... [ ok ] * suid/sgid file(s) with suspicious hardlink(s): * * /usr/share/webapps/webdavcgi/0.8.3/hostroot/cgi-bin/webdavwrapper * * See the Gentoo Security Handbook guide for advice on how to proceed. No amount of "emerge -vC" exposed anything untoward in the package in question. However, as a workaround, I simply manually deleted the problem hardlink first, and then "emerge -vC" removed it as expected. I haven't tested other versions yet, but that portage doesn't really help with this situation either could also be considered a bug. Portage 2.3.13 (python 2.7.14-final-0, default/linux/amd64/17.1/no-multilib, gcc-7.2.0, glibc-2.25-r9, 4.9.6-gentoo-r1 x86_64) ================================================================= System uname: Linux-4.9.6-gentoo-r1-x86_64-Intel-R-_Core-TM-2_Duo_CPU_E6750_@_2.66GHz-with-gentoo-2.4.1 KiB Mem: 2042732 total, 23020 free KiB Swap: 18588764 total, 18563556 free Head commit of repository gentoo: a3eb2c57d1291891a394a07ce0747086b0f87692 sh bash 4.3_p48-r1 ld GNU ld (Gentoo 2.29.1 p3) 2.29.1 ccache version 3.2.4 [enabled] app-shells/bash: 4.3_p48-r1::gentoo dev-lang/perl: 5.28.9999::gentoo dev-lang/python: 2.7.14-r1::gentoo, 3.5.4-r1::gentoo dev-util/ccache: 3.2.4::gentoo dev-util/cmake: 3.8.2::gentoo sys-apps/baselayout: 2.4.1-r2::gentoo sys-apps/openrc: 0.34.11::gentoo sys-apps/sandbox: 2.10-r4::gentoo sys-devel/autoconf: 2.69::gentoo sys-devel/automake: 1.15.1-r1::gentoo sys-devel/binutils: 2.29.1-r1::gentoo sys-devel/gcc: 7.2.0::gentoo sys-devel/gcc-config: 1.8-r1::gentoo sys-devel/libtool: 2.4.6-r3::gentoo sys-devel/make: 4.2.1::gentoo sys-kernel/linux-headers: 4.4::gentoo (virtual/os-headers) sys-libs/glibc: 2.25-r9::gentoo Repositories: gentoo location: /usr/portage sync-type: git sync-uri: https://github.com/gentoo/gentoo.git priority: -1000
The relevant part of the Security Handbook regarding hard links is at the bottom of the page here: https://wiki.gentoo.org/wiki/Security_Handbook/File_permissions#SUID.2FSGID_binaries_and_hard_links Also see bug 81097.
I would suppose to simply delete webdavcgi-0.8.3 (and 0.8.4 probably as well) from the tree, as the version is quite old and the switch away from using the 'webapp' functions was done quite a while ago. This was the main reason for keeping it around, so that the users might have some time to adapt to the new installation.
(In reply to Christian Affolter from comment #2) > I would suppose s/suppose/propose/
I've decided to drop the legacy ebuild(s) which should solve this issue. The PR is available on GitHub: https://github.com/gentoo/gentoo/pull/10826
