In /etc/make.conf.example it states, under the description of PORT_LOGDIR: "Permissions will be modified as needed IF the directory exists" In my opinion it should not do so. I should be able to set whatever permissions I want on that directory so certain users or groups are allowed to read the logs. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Portage cannot drop privs and use logs if it does not set them to something it can write to. If you do not use userpriv, it does not change the permissions.
What's userpriv?
OK, I discovered userpriv is an option in the FEATURES keyword which makes it compile as the "portage" user instead of root. I can see how it has to do something about the permissions if it can't write to the directory. But at least I don't see why it has to remove the world readable and executable bits, which it did. It could leave those the way they are while changing the other permission bits.
Fixed on or before 2.0.51.22-r1
Looking through the batch of bugs, I'm not sure that some of these are actually fixed in stable. Others, the requirements have possibly changed after the initial fix was committed. If you think this bug has been closed incorrectly, please reopen or ask that it be reopened.
Not fixed. I'm now using portage-2.0.51.22-r1. I did a test of changing the permissions of /var/log/portage to world executable, went back later to check, and something changed them back. I was able to work around it by changing the group of the folder to portage instead of root. This way I'm allowed to read the logs. Nevertheless a complete fix would be better, unless there's a good reason for changing the read and execute bits.
Putting a hold on feature requests for portage as they are drowning out the bugs. Most of these features should be available in the next major version of portage. But for the time being, they are just drowning out the major bugs and delaying the next version's progress. Any bugs that contain patches and any bugs for etc-update or dispatch-conf can be reopened. Sorry, I'm just not good enough with bugzilla. ;)
Reopening for consideration (no clue if this is fixed or not).
I think this is fixed by using apply_permissions().
In svn r6743 I've fixed it to only apply permissions when the directory is created automatically.
Created attachment 121313 [details, diff] only set permissions on PORT_LOGDIR if it is created automatically
This has been released in 2.1.2.10.
(In reply to comment #11) You forgot to update: /main/branches/2.1.2/cnf/make.conf /main/branches/2.1.3/cnf/make.conf /main/trunk/cnf/make.conf
Thanks, updated in r6811.