Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FR] Complain about unreadable portage configs #113

Open
burunduk3 opened this issue Aug 13, 2023 · 6 comments
Open

[FR] Complain about unreadable portage configs #113

burunduk3 opened this issue Aug 13, 2023 · 6 comments

Comments

@burunduk3
Copy link

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
Copy link
Owner

vaeth commented Aug 13, 2023

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.

@vaeth vaeth closed this as completed Aug 13, 2023
@vaeth vaeth added the wontfix label Aug 13, 2023
@burunduk3
Copy link
Author

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
Copy link
Author

burunduk3 commented Aug 13, 2023

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
Copy link
Owner

vaeth commented Aug 13, 2023

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.

@vaeth vaeth reopened this Aug 13, 2023
@eugene-bright
Copy link

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

@eugene-bright
Copy link

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

chmod +rx /etc/portage/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants