I suggest (and use) this modification to /usr/sbin/ebuild.sh: It sets mode& group if environment variable PORTAGE_GROUP is set. cd /linux/3/usr/sbin/ diff --unified -b -B /linux/9/usr/sbin/ebuild.sh /linux/3/usr/sbin/ebuild.sh --- /linux/9/usr/sbin/ebuild.sh Thu Sep 26 18:04:15 2002 +++ /linux/3/usr/sbin/ebuild.sh Thu Oct 3 12:41:08 2002 @@ -301,7 +301,13 @@ return 0 fi fi - install -m0700 -d ${WORKDIR} + if [ -z ${PORTAGE_GROUP} ] + then + install --mode 0700 -d ${WORKDIR} + else + install --mode 0770 --group ${PORTAGE_GROUP} -d ${WORKDIR} + fi + [ -d "$WORKDIR" ] && cd ${WORKDIR} echo ">>> Unpacking source..." src_unpack Diff finished at Thu Oct 3 13:18:13
portage 2.0.47 sets all these directories/files to the portage group ... so add those users to the portage group ...
i still am not satisfied. in fact *nothing* has changed here: now the directory is chmod portage.portage, but still only 1 (one) user can access it. I want to use the group feature of unix fs. why not ? so i'm still forced to patch my ebuil.sh w/: install -m0770 -d ${WORKDIR}
Michal has a point. It doesn't matter if the user IS in the portage group, because the directory has NO group permissions. Only owner permissions.
I've spent the last year making this 1-character (a digit in fact) patch manually after every portage install. Is there any negative side to it, that impedes the patch to be accepted? (700 -> 770)
...my vote, too! Radek
Quotes are _required_ on -z tests, btw. Will need to make sure that the directory is always changed to a particular group if this is to be added. Relaxing permissions is always a potential security problem. I don't understand why you need access to that directory anyway. Only reason I can think of is compiling that requires source from another package... or something to that effect.
what i'm asking for, is just the change of the mode: 770 instead of the 700. The reason is, that for some packages i want to access the sources with my editor to read the code (that's what i have keepwork in FEATURES for).
Here is an updated patch for this. $WORKDIR is owned portage:portage, so we just need to change it's ownership to allow group access. The contents of $WORKDIR are already more relaxed than 770. --- ebuild.sh.orig 2004-12-13 22:03:53.666940312 -0800 +++ ebuild.sh 2004-12-13 22:04:09.392549656 -0800 @@ -627,7 +627,7 @@ fi fi - install -m0700 -d "${WORKDIR}" || die "Failed to create dir '${WORKDIR}'" + install -m0770 -d "${WORKDIR}" || die "Failed to create dir '${WORKDIR}'" [ -d "$WORKDIR" ] && cd "${WORKDIR}" echo ">>> Unpacking source..." src_unpack
Honestly, I don't see the point in this not being included in some form (eg, I should get off my ass and do it).
*** Bug 107363 has been marked as a duplicate of this bug. ***
(In reply to comment #1) >portage 2.0.47 sets all these directories/files to the portage group ... > so add those users to the portage group ... It doesn't set all those dors/files to group portage in version 2.0.51.22-r2: * sys-apps/portage : [ I] 2.0.51.22-r2 (0) olberd@ip10 /var/tmp/portage/gdbm-1.8.3-r2 $ ls -la totalt 17K drwxr-xr-x 5 portage portage 160 6 okt 15:35 . drwxrwxr-x 503 portage portage 18K 6 okt 15:34 .. drwxr-xr-x 2 root root 88 6 okt 15:35 build-info drwxrws--- 2 portage portage 144 6 okt 15:35 temp -rw-r--r-- 1 root root 0 6 okt 15:35 .unpacked drwx------ 3 root root 80 6 okt 15:35 work Only temp dir. (In reply to comment #10) > *** Bug 107363 has been marked as a duplicate of this bug. *** As you can see in this duplicate, there are more implications of this than just the fact that users in group portage can't access the workdir content. A user in group portage has permission to run: ebuild some.ebuild unpack in which case the ebuild will be unpacked in workdir with the user as owner and users as group.
Users being able to work with ebuilds is intentional. You're bug is that the dirs are 0770. This bug is that the dirs are 0770. There is no important difference beyond that.
(In reply to comment #12) > Users being able to work with ebuilds is intentional. You're bug is that the > dirs are 0770. This bug is that the dirs are 0770. There is no important > difference beyond that. 0770 isn't the only thing. If the dirs are made to 0770 then all in group users will have access to the workdir generated by a user running ebuild some.ebuild unpack. Which should only be accessible to those in the portage group. I suggest that the dirs should be chmod to portage:portage and have mode 0770.
Well, if ebuild is called by a user at most the group could be adjusted (see chown(2)), and for that we have to make sure that the user is a member of the portage group. Should rather chmod 007 when called as user. As for the 077, that should be optional (and default to off), as people might be in the portage group so they can use search and pretend but shouldn't have the capability to interfere with a running build process. Or could follow the idea of the original patch (though PORTAGE_GROUP sucks as a name for this). Opinions?
In svn r2901 I've added a new PORTAGE_WORKDIR_MODE config variable so that the mode of WORKDIR is no longer hard coded. It is now possible to set PORTAGE_WORKDIR_MODE="0770" in make.conf.
released in 2.1_pre7
In svn r5904 PORTAGE_WORKDIR_MODE is now documented in make.conf.5.
