Summary: | app-portage/eix-0.26.4 can't work with self db | ||
---|---|---|---|
Product: | Portage Development | Reporter: | megabaks <megagreener> |
Component: | Third-Party Tools | Assignee: | Martin Väth <martin> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | kostik.russia, taaroa |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
megabaks
2012-09-14 08:09:30 UTC
The same problem on version 0.25.5. Same here. mkdir /var/cache/eix/ touch /var/cache/eix/portage.eix chown portage:portage /var/cache/eix/portage.eix ----------- dirty hack, because this is eix-update's work just return class Permissions in the eix-update.cc ( and some deps ) or some analog curent version not works correctly anyway > rm -rf /var/cache/eix You shouldn't do this. You can _clean_ this directory, but you should not remove it or change its permissions (unless you really need different permissions for some reason). > dirty hack, because this is eix-update's work Quite the opposite: It is not a user program's task to create random directories or files in /var/cache whose creation requires root permissions. _This_ was a horrible hack, necessary only because eix did not have a dedicated directory for which it had write permissions. Finally, this security hole has been closed. I do not plan to reintroduce it. (BTW: class Permissions was meant for a single file, not for a subdirectory setup. Also, portage:portage is correct only for the default user "portage" which is undesired or even nonexistent in several systems. Finally, changing permissions is not possible anyway, because eix-update drops root permissions ASAP; eix-update simply is so complex that it should not run as root.) Security and convenience always go against each other, but if in doubt, I decide for security. |