doins modifies parent directory's permissions As of portage_2_0_51_rc9 (taken from cvs tag) the doins utility modifies the permission of the parent directory of where the stuff is to be installed, because it executes a `dodir` on that dir. That way it assigns the permissions of the most recent diropts call. One could even consider this as a security issue, because it can lead to information disclosure on a multiuser system in conclusion with ebuilds that don't know the problem. Workaround for ebuild authors: Put all dodir stuff at the end of the install function (not that intuitive :-) Reproducible: Always Steps to Reproduce: write a sample ebuild, which contains for example the following: src_install() { diropts -m 700 dodir /etc/foo diropts -m 755 dodir /usr/lib/bar insinto /etc/foo # the following implicitly calls dodir /etc/foo with diropts -m 755! # which is obviously wrong. doins baz } Actual Results: /etc/foo has 755 permissions. Expected Results: keep 700 permissions. Portage 2.0.51-r2 (default-x86-1.4, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.4.27 i686)
my fault, here's a patch: Index: doins =================================================================== RCS file: /var/cvsroot/gentoo-src/portage/bin/doins,v retrieving revision 1.7 diff -u -B -r1.7 doins --- doins 10 Oct 2004 10:07:20 -0000 1.7 +++ doins 3 Nov 2004 00:08:36 -0000 @@ -20,7 +20,7 @@ exit 1 fi -dodir "${INSDESTTREE}" +[ ! -d "${INSDESTTREE}" ] && dodir "${INSDESTTREE}" for x in "$@" ; do if [ -L "$x" ] ; then
Shouldn't it be [ ! -d "${D}${INSDESTTREE}" ] && dodir "${INSDESTTREE}" instead of [ ! -d "${INSDESTTREE}" ] && dodir "${INSDESTTREE}" ?
*** Bug 73854 has been marked as a duplicate of this bug. ***
*** Bug 73856 has been marked as a duplicate of this bug. ***
Sven, the issue in comment 2 also breaks net-fs/nfs-utils. Will this be fixed at least in CVS?
it's already in cvs and has been for a while Keywords on this bug lists 'InCVS'
No, it is not. http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/bin/doins?rev=1.8&root=gentoo-src&content-type=text/vnd.viewcvs-markup Line 23: [ ! -d "${INSDESTTREE}" ] && dodir "${INSDESTTREE}" As noted in comment 2, this should be [ ! -d "${D}${INSDESTTREE}" ] && dodir "${INSDESTTREE}" Look at bug 73854 and bug 73856 - these are marked as a duplicate of this bug for a reason. Because the "${D}" is missing from the -d test, the target directory is not created inside ${D}.
Sorry, wrong link; that should have been http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/bin/doins?rev=HEAD&root=gentoo-src&content-type=text/vnd.viewcvs-markup Anyway, it still needs fixing.
*** Bug 74857 has been marked as a duplicate of this bug. ***
OK, it's fixed on portage_2_0 now, but MAIN is still broken.
who cares is HEAD is broken really, releases arent done from HEAD
*** Bug 74975 has been marked as a duplicate of this bug. ***
*** Bug 74977 has been marked as a duplicate of this bug. ***
*** Bug 76317 has been marked as a duplicate of this bug. ***
*** Bug 77406 has been marked as a duplicate of this bug. ***
2 months since this bug was filed, a 'fix' was implemented, got into ~x86 (amongst things) and causes all files destined for /etc/conf.d (via newconfd -> doins) _not_ to be installed. Comment Nr 7. has the solution. Note: This is something that bites anyone with a ~x86 in the ass, possibly more people with other ~XXX settings. It is _not_ something that only lives in CVS, moreso, the proposed fix (see comment nr7) is not implemented yet. No matter wether releases are done or not via HEAD in cvs, the bug is there, people are being bitten by it, the fix is here, and is (quite) trivial, but not a hint of a fix somewhere in here. Just a growing list of 'duplicates' (which should be a hint). Any ETA on the real fix getting into portage somewhere?
>2 months since this bug was filed >the bug is there, people are being bitten by it I'm still getting bit by this and it has been awhile. Can't build up an ~x86 system without jumping through hoops. I am wondering as well why portage still remains broken and this hasn't been resolved yet. This isn't, AFAIK, just a trivial application in Gentoo-land. Is the proposed fix not really a total or proper solution? Does it lead to more breakage somewhere else?
*** Bug 77558 has been marked as a duplicate of this bug. ***
After running into this bug (part of 93636), just wondering if there's a reason noone has committed such a trivial fix?
this has already been fixed & released
Sorry, was referring to HEAD.
Spanky, care to check into head on this?
i already did :p
