Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT

[Ciaran McCreesh]

On Fri, 12 Jan 2007 16:02:01 +0900 Georgi Georgiev <chutz@×××.net>
wrote:
| Why would it not be removed? Upstream installs in the sandbox, the  
| contents of the sandbox are recorded in the package database and
| with collision-protect it will not override random stuff on my
| computer.

Unless upstream decides to override the sandbox sneakily, or uses one
of the many tricks to get content onto the live filesystem that Portage
won't handle.

| If I uninstall the package without ever touching it,
| everything will be removed. I do exclude the pkg_* phases from the
| above, but we already agreed that nothing from upstream executes
| there.

Not true. Not in the sliiiiiightest bit true. There are approximately
three zillion quirks in how Portage handles the merge which would allow
one to slip something through the cracks. Examples include overwriting
directories with files and installing non-(directories|symlinks|files).
Or if you want examples that will also work with package managers that
are more secure than Portage, think installing cron.d entries to create
malicious content.

| Still, your point makes sense. But I hope that you will agree that
| as long as FEATURES=userpriv exists it should be enforced. If it can
| be circumvented the FEATURE may as well be removed and the whole
| problem dealt with.

No. userpriv is a nice safety feature to prevent against *accidental*
screwups, but it has absolutely no value as a security feature. There
are a small number of occasions where it really does need to be
disabled, and that option should be available for the ebuild author
without the need to worry about silly users refusing to install the
package merely because of their misunderstanding of what userpriv does.

-- 
Ciaran McCreesh
Mail                                : ciaranm at ciaranm.org
Web                                 : http://ciaranm.org/
Paludis, the secure package manager : http://paludis.pioto.org/