Bugzilla Bug 136445

RESTRICT="usersandbox" is not honored by portage... not really sure what you
are after here.

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.

(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.

Fixed in CVS, thanks.

Still there in qmail-scanner ebuilds... ;)

 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

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.

*** Bug 148815 has been marked as a duplicate of this bug. ***

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.

# 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.