the merge file etc-update uses while merging configuration files is created with umask based permissions instead of permissions like that of the files being merged ... i forget how i came across this originally, but it was just something i noticed randomly so if you have: /etc/foo - 0700 /etc/._cfg0000_foo - 0700 and you go to merge these, during the merge process the file: /etc/foo.merged will most likely be created with 0644 ... granted, this depends on the umask set for the user (probably root) running `etc-update`, but there's no reason this cant be handled securely i dont know if people wish to issue a GLSA (would have to release a fixed version of portage first) the exact fix is: http://sources.gentoo.org/viewcvs.py/portage?rev=7799&view=rev any input on how i fixed it would of course be welcomed, but the details are merely: - create tmpdir - force permission of tmpdir to 0700 - force ownership to user running `etc-update` - store temp merged file in the tmpdir - change the permission/ownership of merged file before overwriting old file
(In reply to comment #0) > the exact fix is: > http://sources.gentoo.org/viewcvs.py/portage?rev=7799&view=rev > any input on how i fixed it would of course be welcomed, but the details are > merely: > - create tmpdir > - force permission of tmpdir to 0700 > - force ownership to user running `etc-update` > - store temp merged file in the tmpdir > - change the permission/ownership of merged file before overwriting old file >=sys-apps/portage-2.1.3.11 has that fix.
the code actually in 2.1.3.11 is the following, which is very unlikely to work: # # Run the script # scriptname=$(basename $0) TMP="${PORTAGE_TMPDIR}/etc-update-$$" trap die term type portageq > /dev/null || exit $? eval $(portageq envvar -v CONFIG_PROTECT \ CONFIG_PROTECT_MASK PORTAGE_CONFIGROOT PORTAGE_TMPDIR ROOT USERLAND) export PORTAGE_TMPDIR I suggest setting PORTAGE_TMPDIR before trying to use it ;).
(In reply to comment #2) > I suggest setting PORTAGE_TMPDIR before trying to use it ;). That's fixed in svn already. It still works, it's just that /etc-update-$$ is used as the temp dir, which is kind of weird.
Just to be sure: This is fixed without known regressions in portage-2.1.3.16 which is going stable per bug 197165? Because it is not listed as blocking bug 194041.
(In reply to comment #4) > Just to be sure: This is fixed without known regressions in portage-2.1.3.16 > which is going stable per bug 197165? That's right.
This one is ready for glsa decision. It somehow slipped through because of the wrong component :-/ I tend to vote YES here.
voting yes too, and this way, we'll be able to safely close #149062.
(In reply to comment #7) > voting yes too, and this way, we'll be able to safely close #149062. Do you plan to release a combo-glsa, because otherwise these two are unrelated.
GLSA 200712-11
