[FR] Complain about unreadable portage configs

[burunduk3]

It happens so that I had files under /etc/portage/package.accept_keywords with permissions of -rw------- root root. While it wasn't problem for emerging stuff, eix appears to switch to the portage user before reading them. As a result I got tons of confusing complains when, for example, running eix-test-obsolete.

What I expect the tool to give me in such a situation would be a error message in output, something like:

eix-text-obsolete: cannot open /etc/portage/package.accept_keywords/default: Permission denied

so I would easily spot the issue and fix the permissions.

A quick glance into the code shows that this might originate from methods like PortageUserConfig::readKeywords, which call pushback_lines to read the portage config files, but instead of providing errtext to pushback_lines just silently return.

[vaeth]

You can use EIX_USER, EIX_GROUP, EIX_UID, EUD_GID to configure the user/group to which eix attempts to change (if possible). It is not an error if eix cannot change to that user (which happens, for instance, if eix is started as a user with insufficient permissions for that), and for a similar reason, it is not an error if eix cannot read files or directories. In fact, the configuration files are practically all optional - for instance, many users do not even have some /etc/portage/package.accept_keywords, even less have an /etc/portage/package.keywords (which is a historical name for the same thing). You would not want to see error messages if these do not exist. Theoretically, if a file cannot be read, one could make deeper investigation about the reason and spit out an errors only in certain cases, but this investigation needs a lot of I/O operation and costs time. Since absent optional config files are more a rule than an exception, this would slow down every call of eix. I do not plan to change this.

[burunduk3]

I agree that missing package.accept_keywords is not an error at all. However, when there is one but eix failed to read it, it is a problem: as I mentioned, eix-text-obsolete's output is full of false-positive, which makes the tool (not the rest of eix, however) practically unusable.

I agree that there are many ways to fix my problem: change permission to 0644, change EIX_USER as you've suggested. However, the tricky part was to spot what's wrong with eix-test-obsolete and my config, and here a small error message could have helped.

[burunduk3]

Theoretically, if a file cannot be read, one could make deeper investigation about the reason and spit out an errors only in certain cases, but this investigation needs a lot of I/O operation and costs time.

Sorry, I didn't understand that. eix already tries to open the user configuration files, so the question is to differentiate between ENOENT and other errno's in case of open failure. This might add more error-handling code (so the cost/profit ratio is questionable), but I don't see any additional I/O operations or even syscalls.

[vaeth]

It might be that an open of a file fails, because it is a directory (which is valid in many cases); conversely, an opendir might fail because it is file (which is also valid in many cases). It might be possible to do some trickery with errno to do the right thing in all cases without additional stat calls, but this requires some investigation. But even if this works (or one is willing to accept such stat calls - I realize that some are done already anyway), it is not so simple to implement, because for the recursive reading, the errors have to be collected.

If you are willing to implement it so that it works for all calls of the methods and the implementation does not cause a severe additional latency, please make a PR. I do not consider the problem important enough to spend so much work on it.

[eugene-bright]

Please set correct permissions using setfacl. You are not limited with owner:group:others bits anymore.

[eugene-bright]

And please also make sure that the dir can be listed and read by everyone.

chmod +rx /etc/portage/