my user is in neither in the portage group or the wheel group. wareid@mayfly wareid $ su - Password: su: Permission denied Sorry. wareid@mayfly wareid $ id uid=1000(wareid) gid=100(users) groups=100(users),18(audio),19(cdrom) wareid@mayfly wareid $ emerge -s portage Searching... [ Results for search key : portage ] [ Applications found : 3 ] * app-admin/kportage Latest version available: 0.6.1 Latest version installed: [ Not Installed ] Size of downloaded files: 484 kB Homepage: http://www.freesoftware.fsf.org/kportage/ Description: A graphical frontend for portage * app-admin/portagemaster Latest version available: 0.2.0 Latest version installed: [ Not Installed ] Size of downloaded files: 32 kB Homepage: http://portagemaster.sourceforge.net Description: A java portage browser and installer. * sys-apps/portage Latest version available: 2.0.47-r6 Latest version installed: 2.0.47-r6 Size of downloaded files: 168 kB Homepage: http://www.gentoo.org Description: Portage ports system wareid@mayfly wareid $ ssh root@localhost root@localhost's password: Last login: Wed Jan 19 19:53:32 2000 mayfly root # emerge info Portage 2.0.47-r6 (default-x86-1.4, gcc-3.2.2, glibc-2.3.2_pre1-r0) ================================================================= System uname: 2.4.20-sparc-r3 i686 Pentium II (Klamath) GENTOO_MIRRORS="ftp://192.168.0.2 http://gentoo.oregonstate.edu/ ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /opt/jakarta/tomcat/conf /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/stuff/portage/" DISTDIR="/stuff/distfiles/" PKGDIR="/stuff/packages/mayfly/" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="/home/wareid/ebuilds/" USE="x86 oss apm avi crypt cups encode gif jpeg libg++ libwww mikmod mmx mpeg ncurses nls pdflib png qtmt quicktime spell truetype xml2 xmms xv zlib gdbm berkdb slang readline arts svga java guile sdl gpm tcpd pam ssl perl python esd imlib oggvorbis gtk qt motif opengl X gtk2 kde tcl gnome -alsa flash -3dnow" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=pentium2 -O3 -pipe -fomit-frame-pointer -fprefetch-loop-arrays -ffast-math -fforce-addr -falign-functions=4" CXXFLAGS="-march=pentium2 -O3 -pipe -fomit-frame-pointer -fprefetch-loop-arrays -ffast-math -fforce-addr -falign-functions=4" ACCEPT_KEYWORDS="x86 ~x86" MAKEOPTS="-j6" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox ccache buildpkg distcc prelink" mayfly root # ------------------------------------------------------------------------- portage 2.0.46-r12 doesn't have this problem. wareid@mercury wareid $ su - Password: su: Permission denied Sorry. wareid@mercury wareid $ id uid=1000(wareid) gid=100(users) groups=100(users),18(audio),19(cdrom) wareid@mercury wareid $ emerge -s portage emerge: wheel group membership required for "--pretend" and search. wareid@mercury wareid $ emerge -p portage emerge: wheel group membership required for "--pretend" and search. wareid@mercury wareid $ ssh root@localhost root@localhost's password: Last login: Wed Feb 26 16:22:18 2003 from confucius.siffy.dyndns.org mercury root # emerge info Portage 2.0.46-r12 (default-x86-1.4, gcc-3.2.1, glibc-2.3.1-r2) ================================================================= System uname: 2.4.20 i586 Pentium 75 - 200 GENTOO_MIRRORS="ftp://192.168.0.3 http://www.ibiblio.org/pub/Linux/distributions/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="" USE="-3dfx -3dnow -aalib acl -afs -alsa -apm -arts -atlas -avi berkdb -bonobo -canna -cdr -cjk crypt -cups -dga -directfb -doc -dvd encode -esd -evo fbcon flash -freewnn -gb -gd gdbm ggi -ggz -gif -gnome -gphoto2 -gpm -gtk -gtk2 -gtkhtml -guile icc icc-pgo imap -imlib innodb ipv6 -java -jikes -jpeg junit -kde kerberos -lcms -ldap -leim libg++ libgda libwww -matrox maildir -mbox -mikmod -mmx -motif -mozilla -mpeg -mule -mysql -nas ncurses -nls -nocardbus oci8 odbc oggvorbis -opengl -oss pam -pcmcia -pda -pdflib perl pic -plotutils -png -pnp postgres python -qt -qtmt -quicktime readline ruby samba sasl -scanner -sdl slang slp snmp socks5 -spell -sse ssl -static -svga -tcltk tcpd -tetex -tiff -truetype -trusted -voodoo3 -wavelan -wmf -X xface -xml -xml2 -xmms -xv -zeo zlib x86" COMPILER="gcc3" CHOST="i586-pc-linux-gnu" CFLAGS="-march=pentium -O3 -pipe -fomit-frame-pointer -fprefetch-loop-arrays -fforce-addr -falign-functions=4" CXXFLAGS="-march=pentium -O3 -pipe -fomit-frame-pointer -fprefetch-loop-arrays -fforce-addr -falign-functions=4" ACCEPT_KEYWORDS="x86" MAKEOPTS="-j1" AUTOCLEAN="yes" SYNC="rsync://192.168.0.3/gentoo-portage" FEATURES="sandbox ccache" mercury root # Reproducible: Always Steps to Reproduce: 1. emerge sync 2. emerge portage 3.
What are you reporting? This doesn't make any sense. What are you failing 'su -' repeatedly?
I think Will doesn't like the fact that user without special permissions can use emerge. So It doesn't look like a "real bug", but more like a feature request. He wants to restric who can run the command. Will, why don't you set permission on the emerge binary ? I think that's the UNIX way to achieve what you want (if I understand correctly). (added self to CC)
To Poster #2:
To Poster #2: He's not asking for a feature. He's clearly stating that Portage 2.0.46-r12 had the correct security permissions and that Portage 2.0.47-r6 does not have the correct security permissions. How is that a feature request? To Poster #1: He's just showing that he's not logged in as root or a root privledged user by running the su command. Not that it's failing. Read above my comment to poster #2 about what he's reporting.
the issue isnt really permissions ... with 2.0.47, non root users are allowed to use certain features of portage (like search) ... the reason being /usr/portage is world readable so why restrict access to the tool when they could in theory view the stuff themselves ? the question should be 'are non root users allowed to use emerge if user is not in the group portage' ?
God damnit, Nick. Can you not fucking read? I specifically said what my problem was on the first line. A normal user is able to use emerge's search and pretend features. They're not supposed to be able to according to your own documentation. This didn't happen until I upgraded to a version that uses the new portage group instead of wheel. Should I refresh your memory on that? einfo "NOTICE: The wheel group requirement for non-root users has been changed to" einfo "group portage. Group portage must be a valid group for user to use portage." and einfo "The 2.0.47 line of portages contains an optional userpriv mode that" einfo "enables portage to drop root privleges and run as a normal user. It is" einfo "enabled via FEATURES by adding userpriv." No, I do not have "userpriv" in my FEATURES. I don't want users to be able to use portage. And to Fernand Albarracin, no it's not a feature request. Why not read what I actually reported as the bug instead of assuming shit? It is a bug. And it's a security bug. Changing the bin's perms every time a new portage comes out is not a fix. It's a pain in the ass workaround to something that used to work and Nick has broken like he has many times before while trying to add fancy shit to portage when he gets bored or something instead of maybe fixing the bugs he has open already. And I thought this was interesting. copied from the Gentoo weekly newsletter http://www.gentoo.org/news/en/gwn/20030224-newsletter.xml The following stable packages were added to portage this week Note: Because of the pending release of 1.4_final, the Portage tree is currently frozen. As such, no new stable packages were introduced to Portage this week Updates to notable packages sys-apps/portage - portage-2.0.47-r2.ebuild; If the "arch" tree is frozen why did this broken portage that couldn't `emerge rsync` hit the x86 and ~x86 tree at the same time? Same with 2.0.47-r6 that I'm complaining about. If the tree is frozen, why are new ebuilds hitting it everyday without ANY testing other than that which the dev does himself/herself? No, the newest version in my tree, portage 2.0.47-r7 doesn't fix my problem. Thanks, Will
Aliz added because this is a security problem that is Gentoo specific and created by portage itself. According to portage's own docs things shouldn't happen this way.
(1) calm down (2) it's not a security issue because search doesnt allow access to information the user doesnt already have access to (3) this portage can `emerge rsync`
Well, obiously there is some confusion going one here. The purpose of my message wasn't some king of public bashing. Sorry if it's the way you saw it. When I said it's a feature request, I assumed that allowing non-privileged users to run "emerge -p" or "emerge -s" was itself a response to some feature requests. I think I remember reading those both on mailing lists and bugzilla some time ago. So I thought you wanted access control on top of that. I wasn't aware of any security implications related to the use of "-p" and "-s". If there is a problem here, you might want to tell why then. Please Will, Bugzilla is not the place for rant. I'm also frustrated when things break, but the only way we can help here is by being productive and by avoiding to waste developer time. Hint: use mailing list and/or private mail. Again, sorry for the confusion. I'll shut up now.
SpanKY, 1. I tried calm. All it did was get me told I didn't know what the hell I was talking about. 2. It is a security issue because users shouldn't have this kind of access to portage (`emerge info`, etc.). It says so right in the portage docs and the ebuild itself that this access should require the group `portage` in the users access rights. 3. I realize it can sync. I wasn't complaining about that. I was complaining about the fact a version that couldn't ever hit the x86 (ie, stable) tree. That should be another bug in itself though, but I can't remember at this second if there's a place to report buggy devs. It'd probably be better if such a thing wasn't implemented. There would be plenty of bugs about you lately as well. Fernand Albarracin, I snapped at you as well, because you didn't seem to read the bug fully yourself. This wasn't the first place I've been brushed off on this. It is a feature request. One that was supported correctly in <.47 for as long as I've been using gentoo. The new feature was the moving of this type access from the `wheel` group to the `portage` group. During this move ALL users got access. I tried to show that by `su -` failure and `id`, but I guess I screwed up by providing too much info and making Nick not even want to read about the problem. I suppose in my attempts to give an accurate example of the situation here (by pasting things that could be skimmed/glanced at for the most part) I wasted the dev's time. He would've asked for everything I'd pasted in his initial reply if I hadn't given it in my original bug post. I was trying to save time.
yes, by your definition, it is a 'security' issue, but it is not the kind of issue that aliz need be concerned with ... this is a portage bug, and a bug that 'reveals' a information in an easier to access format ... so lets just drop the flame fest, everyone make nice nices, and wait till nick fixes it ... as for whether this should have hit stable, noone's perfect, we just try to be ... again, lets all hug
The reason you need to be in group portage is for dep generation. Non-portage/root users do not have permissions to the trees required to create the files necessary to complete the process. It doesn't say you can't try. The security purpose of wheel/portage is so that users can't modify files that portage/wheel/root will use later for compilation. 'userpriv' is compilation mode, not a user-rights option. Portage is not setuid/setgid so it can't access anything that the running user can't access. _Anyone_ can rsync a portage tree and get the exact information it would be allowing them to look at anyway. Security-wise, /var/db/pkg is the only tree which would contain anything you could consider a security-risk, but anyone with a shell could access all that information in a slightly more tedious form using 'ls' and '--verbose' in various commands. If you really insist on being that restrictive, a simple chmod on a few dirs and bins will prevent any reasonable access. chmod 0700 /var/tmp/portage /var/db/pkg /usr/portage chmod 0700 /usr/lib/portage/bin chmod 0700 /usr/lib/python2.2/site-packages/portage.py chmod 0700 /etc/make.globals /etc/make.conf /etc/make.profile rsync will revert make.profile back to 755, so you'll have to maintain that one after every rsync.
Works for me and haven't gotten any further argument otherwise.
