On Fri, 12 Jan 2007 16:02:01 +0900 Georgi Georgiev <[EMAIL PROTECTED]> 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/
signature.asc
Description: PGP signature
