Bug 644828 – www-apps/webdavcgi-0.8.3[suid] breaks depclean

• Product: Gentoo Linux
• Status: CONFIRMED ---

[Description Kent Fredric (IRC: kent\n) (RETIRED) 2018-01-17 01:13:36 UTC]

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

[Comment 1 Zac Medico 2018-01-17 01:33:59 UTC]

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.

[Comment 2 Christian Affolter 2018-06-26 17:04:06 UTC]

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.

[Comment 3 Christian Affolter 2018-06-26 17:06:35 UTC]

(In reply to Christian Affolter from comment #2)
> I would suppose
s/suppose/propose/

[Comment 4 Christian Affolter 2019-01-17 13:48:49 UTC]

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