This seems odd.. shouldn't root always be able to write the file? % sudo eix-update Reading Portage settings .. Building database (/var/cache/eix/portage.eix) .. [0] "gentoo" /var/tmp/ro-portage/ (cache: metadata-md5-or-flat) Reading category 154|154 (100%) Finished [1] "" /var/lib/layman/darkside (cache: parse|ebuild*#metadata-md5#metadata-flat#assign) Reading category 154|154 (100%) Finished Applying masks .. Calculating hash tables .. Writing database file /var/cache/eix/portage.eix .. void update(const char*, CacheTable&, PortageSettings&, const std::vector<RepoName, std::allocator<RepoName> >&, const std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&, Statusline&): Can't open the database file '/var/cache/eix/portage.eix' for writing (mode = 'wb')
The first thing eix(-update) attempts to do - after reading the configuration files - is to change to the permissions of $EIX_USER:$EIX_GROUP (which defaults to portage:portage) if it can. This is done to avoid working with root permissions as soon as possible, i.e. it is intentional that "sudo" does not give additional permissions. For this reason, the directory /var/cache/eix should be have the permsissions 775 (for portage:portage) so that portage user/group can write to it.
In other words, you want people to add user root to portage group to successfully run eix-* as root?
(In reply to comment #2) > In other words, you want people to add user root to portage group to > successfully run eix-* as root? I do not understand: If /var/cache/eix is 775 and belongs to portage:portage and eix-update is run as root, then there should be no permission problems: The eix-update process becomes automatically owned by portage:portage, and so eix-update should be able to write to /var/cache/eix. The only thing which must match is the owner (or group) of /var/cache/eix and the values of the variables EIX_USER/USER_GROUP.
(In reply to comment #3) > variables EIX_USER/USER_GROUP. Typo: I meant EIX_USER/EIX_GROUP.
(In reply to comment #3) > (In reply to comment #2) > > In other words, you want people to add user root to portage group to > > successfully run eix-* as root? > > I do not understand: If > /var/cache/eix is 775 and belongs to portage:portage > and eix-update is run as root, then there should be no permission problems: Under the above conditions, the error output in comment #0 happens.
Created attachment 305915 [details, diff] Print debug info for set*id() This sounds very strange. I cannot reproduce it here. Please recompile with the attached patch and post the output.
I noticed eix now creates database with system wide umask: # umask 0077 # ls -lah /var/cache/eix razem 11M drwxrwxr-x 2 portage portage 4,0K 03-16 09:28 . drwxr-xr-x 12 root root 4,0K 03-15 09:33 .. -rw-r--r-- 1 root root 0 03-15 09:33 .keep_app-portage_eix-0 -rw------- 1 portage portage 5,2M 03-21 09:30 portage.eix -rw------- 1 portage portage 5,2M 03-20 13:34 previous.eix Now only root (and user 'portage') can use eix. It could be better to have o+r permissions.
(In reply to comment #7) > I noticed eix now creates database with system wide umask: You are right: It probably makes no sense to honour the user's/root's umask when creating the cachefile in the default location. The umask is now overridden without option -o in the eix git master on BerliOs (>=eix-0.25.4)
Jeremy, was this umask thing really related with your problem? If not and if it is still unclear what is going on, please post the information which is output by the attached patch (and, if possible, please try to find out why the functions output by that patch do not give you the required permissions in your case: Maybe you have some special SELinux or other non-Unix permission setups?)
+*eix-0.25.4 (06 May 2012) + + 06 May 2012; Jeremy Olexa <darkside@gentoo.org> -eix-0.25.0.ebuild, + +eix-0.25.4.ebuild: + Version bump, mostly bug fixes. Closes Gentoo bugs 410205 & 408509
# eix -V eix 0.25.4 (gcc-4.6.3, x86_64-pc-linux-gnu) # ls -lah /var/cache/eix razem 11M drwxrwxr-x 2 portage portage 4,0K 05-07 09:18 . drwxr-xr-x 12 root root 4,0K 05-07 09:22 .. -rw-r--r-- 1 root root 0 05-07 09:18 .keep_app-portage_eix-0 -rw------- 1 portage portage 5,4M 05-07 09:22 portage.eix -rw------- 1 portage portage 5,3M 05-02 09:17 previous.eix It looks eix still doesn't set 755 on own database file.
(In reply to comment #11) > It looks eix still doesn't set 755 on own database file. It does never modify permissions of existing files (which would be rather intrusive). But if you remove the old files, the new ones should be generated with 755, independent of your umask.
You are completly right, i removed previous.eix file only. Ok, eix creates file with correct permissions. Thanks.
*** Bug 420029 has been marked as a duplicate of this bug. ***
