136445 2006-06-11 10:41 0000 mail-filter/qmail-scanner - invalid RESTRICT="usersandbox" 2007-12-13 22:54:32 0000 1 1 1 Unclassified Gentoo Linux Ebuilds 2006.0 All Linux RESOLVED FIXED P2 normal --- 1 jakub@gentoo.org qmail-bugs@gentoo.org anf@ltmd.org dev-portage@gentoo.org patrick@gentoo.org jakub@gentoo.org 2006-06-11 10:41:16 0000 RESTRICT="usersandbox" is not honored by portage... not really sure what you are after here. robbat2@gentoo.org 2006-06-11 13:37:13 0000 IIRC, the packages fail to compile if you have FEATURES=usersandbox. userpriv on it's own is fine, and sandbox on it's own is fine. jakub@gentoo.org 2006-06-11 13:47:36 0000 (In reply to comment #1) > IIRC, the packages fail to compile if you have FEATURES=usersandbox. > userpriv on it's own is fine, and sandbox on it's own is fine. Well, it doesn't do anything useful, portage ignores it. :) According to changelog, this has been added for Bug 93447 in qmail-scanner. RESTRICT="userpriv" is the effective restrict there, that usersandbox thing is just redundant and silently ignored. As for qmail, this has been added for Bug 99390. It seems kinda redundant to me, the bug was about tests, those are restricted, so there's no need for additional restrictions there, or does it fail w/ userpriv as well without tests enabled? Couldn't find anything useful wrt these restricts in changelog for netqmail. hansmi@gentoo.org 2006-06-17 04:33:56 0000 Fixed in CVS, thanks. jakub@gentoo.org 2006-06-19 15:21:45 0000 Still there in qmail-scanner ebuilds... ;) jakub@gentoo.org 2006-07-21 02:29:13 0000 20 Jul 2006; Michael Sterrett <mr_bones_@gentoo.org> qmail-scanner-1.25-r1.ebuild, qmail-scanner-2.01.ebuild: usersandbox => sandbox since usersandbox isn't a valid RESTRICT robbat2@gentoo.org 2006-07-21 02:53:29 0000 Reopening this. Usersandbox needs to become a valid RESTRICT. qmail-scanner is a special case. The 'configure' script has always been heavily hacked by upstream, and has in the past done unsafe things - mainly around writing to the stuff used by an active install of qmail-scanner, and breaking the installed copy by doing so (and losing mail). With FEATURES='userpriv' OR FEATURES='sandbox', it compiles and works fine (and the compile is safe). FEATURES='userpriv sandbox' is the same as FEATURES='userpriv' (sandbox is not used). With FEATURES='-sandbox', it compiles, but you're vulnerable to upstream stupidity. With FEATURES='userpriv usersandbox', it fails to compile and work properly. So specifically, we want to ONLY block usersandbox. Mr_bones_: would you please revert your "usersandbox => sandbox" change ASAP to avoid qmail-scanner breaking existing systems. jakub@gentoo.org 2006-09-23 11:34:43 0000 *** Bug 148815 has been marked as a duplicate of this bug. *** anf@ltmd.org 2007-06-14 11:47:25 0000 I remembered, that I've workarounded this problem downgrading clamav, installed qmail-scanner and after that upgrading clamav. But with latest clamav versions you cannot reemerge mail-filter/qmail-scanner. jakub@gentoo.org 2007-12-13 22:54:32 0000 # grep RESTRICT *.ebuild qmail-scanner-1.25-r1.ebuild:RESTRICT="userpriv" qmail-scanner-2.01.ebuild:RESTRICT="userpriv" (In reply to comment #6) > Reopening this. > Usersandbox needs to become a valid RESTRICT. Why? RESTRICT="usersandbox" will yield you either effective FEATURES='userpriv sandbox' (which translates to running as portage:portage without a sandbox) or effective FEATURES='sandbox' (sandboxed with root privs). What's the exact expected benefit from making usersandbox a valid restrict I really fail to see, you already get FEATURES='sandbox' with the current RESTRICT="userpriv". Closing this as the RESTRICT is fixed.