At least 42 ebuilds in the portage snapshot dated 20060301 utilize enewuser and/or enewgroup only within the src_compile() or src_install() functions. When installing binary packages the user and/or group will not be created. At worst the installed binary package will end up running with incorrect ownership and possibly pose a security risk to those who use them, with little or no indication a problem exists.
Here are the ebuilds I found: app-misc/dnetc/dnetc-2.9011.497.ebuild app-misc/klive/klive-0.16.ebuild dev-db/c-jdbc/c-jdbc-1.0.4-r1.ebuild dev-util/perforce-proxy/perforce-proxy-2003.1.ebuild dev-util/perforce-proxy/perforce-proxy-2003.2.ebuild dev-util/perforce-server/perforce-server-2003.2.ebuild dev-util/perforce/perforce-2002.2.ebuild dev-util/perforce/perforce-2002.2-r1.ebuild dev-util/perforce/perforce-2003.1.ebuild dev-util/perforce/perforce-2003.1-r1.ebuild net-dns/bind/bind-9.2.5-r6.ebuild net-dns/bind/bind-9.2.6.ebuild net-dns/bind/bind-9.3.2.ebuild net-ftp/jftpgw/jftpgw-0.13.4-r1.ebuild net-im/ejabberd/ejabberd-0.7.5.ebuild net-im/jabber-base/jabber-base-0.00.ebuild net-im/jabberd/jabberd-1.4.3-r4.ebuild net-im/jabberd/jabberd-1.4.3-r5.ebuild net-im/jabberd/jabberd-2.0.10.ebuild net-im/jabberd/jabberd-2.0.9.ebuild net-misc/ser/ser-0.9.0.ebuild net-misc/ser/ser-0.9.4.ebuild net-misc/spread/spread-3.17.3.ebuild net-misc/tor/tor-0.1.0.14-r1.ebuild net-misc/tor/tor-0.1.0.16.ebuild net-misc/tor/tor-0.1.0.17.ebuild net-p2p/amule/amule-2.0.1-r2.ebuild net-p2p/amule/amule-2.0.3-r4.ebuild net-p2p/amule/amule-2.1.0-r1.ebuild net-www/apache-2.0.54-r9.ebuild net-www/apache-2.0.54-r15.ebuild net-www/apache-2.0.54-r16.ebuild net-www/apache-2.0.54-r30.ebuild sys-apps/ivman/ivman-0.6.4.ebuild sys-apps/ivman/ivman-0.6.5.ebuild sys-apps/ivman/ivman-0.6.6.ebuild sys-apps/ivman/ivman-0.6.8.ebuild sys-apps/ivman/ivman-0.6.9.ebuild www-apps/trac-0.9.4.ebuild www-servers/tomcat/tomcat-5.0.28-r9.ebuild www-servers/tomcat/tomcat-5.0.28-r10.ebuild www-servers/tomcat/tomcat-5.0.28-r12.ebuild
CCing maintainers. - apache is irrelevant, there's a later fixed version stable across the board - app-misc/dnetc has no maintainer - net-ftp/jftpgw has no maintainer - net-misc/ser has no maintainer
(In reply to comment #2) > CCing maintainers. > > - apache is irrelevant, there's a later fixed version stable across the board > - app-misc/dnetc has no maintainer > - net-ftp/jftpgw has no maintainer > - net-misc/ser has no maintainer > Apache is irrelevant? If someone out there installed 2.0.54-r30 from a binary compiled on another system, or in a chroot, what happens as a result of the following? # protect the suexec binary if ! useq no-suexec; then fowners root:apache /usr/sbin/suexec fperms 4710 /usr/sbin/suexec fi
guess i could update enew{user,group} to fail if called inside of a src_* func
Failing will break even more stuff. A carefully written warning is more sensible.
(In reply to comment #4) > guess i could update enew{user,group} to fail if called inside of a src_* func > Should it _ever_ be in anything other than pkg_setup(), pkg_preinst() or pkg_postinst()? What happens when fowners is used in src_* with a user/group that does not exist other than being created (later?) in pkg_preinst()?
(In reply to comment #5) > Failing will break even more stuff. A carefully written warning is more > sensible. > I would prefer the install fail instead of leaving my system in a possibly insecure and inconsistent state. Currently it just displays an error message (invalid user) and continues on unless the maintainer sticks a die in there. Call me anal.
> Failing will break even more stuff. A carefully written warning is more > sensible. i'll wait until these packages are fixed then make it a failure > Should it _ever_ be in anything other than pkg_setup(), pkg_preinst() or > pkg_postinst()? now > What happens when fowners is used in src_* with a user/group that does not > exist other than being created (later?) in pkg_preinst()? it'll obviously fail ... fowners is just a glorified chown
www-apps/trac-0.9.4.ebuild done.
c-jdbc and tomcat fixed so java should be done
*** Bug 124647 has been marked as a duplicate of this bug. ***
net-dns/bind and app-misc/dnetc fixed.
(In reply to comment #12) > net-dns/bind and app-misc/dnetc fixed. > Not everything is fixed in this bug.
ivman is done.
well packages will now start failing to emerge so you maintainers may want to fix your stuff
net-www/apache-2.0.55-r1 fails too
As far as I can see, _all_ current apache ebuilds fail. See bug #130459.
It would have been nice if apache-bugs was CCed on this before you broke our package. It's now fixed, thanks to chtekk.
Flameeyes fixed klive, thankyee
What about the apache 1? >>> Install apache-1.3.34-r11 into /var/tmp/portage/apache-1.3.34-r11/image/ category net-www * 'enewgroup()' called from 'install()' which is not a pkg_* function. * Package fails at QA and at life. Please file a bug. And yes my portage is uptodate. B-)
Well I have another question, I store my users in an ldap database, and I'm using pam_ldap and nss_ldap, when an ebuild tries to create a user that already exists in ldap, the ebuild fails. >>> emerge (1 of 1) net-www/apache-2.0.55-r1 to / >>> extracting info * * LFS support has been removed due to incompatibilites with other packages. * You _will_ have to re-emerge any Apache modules you have installed, or * they will likely misbehave/segfault. * * * Multiple MPM support has been disabled due to problems with external * modules. If you have relied on this functionality you will need * to find another solution. The Gentoo Apache team apologizes for * any inconvienence this may cause you. * >>> extracting apache-2.0.55-r1 >>> Merging net-www/apache-2.0.55-r1 to / * Adding group 'apache' to your system ... * - Groupid: 81 groupadd: name apache is not unique !!! FAILED preinst: 1 enew(user|group) should first check if user exists besides the /etc/group and /etc/passwd # cat /etc/passwd | grep apache (ouputs nothing) # cat /etc/group | grep apache (ouputs nothing) # getent passwd | grep apache apache:x:81:81:added by portage for apache:/var/www:/usr/sbin/nologin # getent group | grep apache apache:x:81:
Pedro, please file a separate bug for that issue, as it isn't related to enewuser/enewgroup being used in src_* functions. Thanks...
Closing; if there's anything left, then it's completely unused and unmaintained cruft that should go to treecleaners.
