| Summary: | [tracker] ebuilds calling enewgroup/enewuser in pkg_setup() - probably not desired in many cases | ||
|---|---|---|---|
| Product: | Documentation | Reporter: | Gordon Malm (RETIRED) <gengor> |
| Component: | Devmanual | Assignee: | Gentoo Devmanual Team <devmanual> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | alexander, alex_y_xu, esycat, kensington, mjo, nimiux, pva, qa, solar, tcunha, xmw |
| Priority: | High | Keywords: | Tracker |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 487172 | ||
| Bug Blocks: | |||
We actually standardized on adding users in pkg_setup() for the simple fact that binary packages are broken when adding the users in pkg_preinst(). Basically because installing a binary package does not call the pkg_preinst() function, so your suggested fix would break packages instead of the current way which has an annoying side effect. Additionally, base-system has nothing to do with this. Allowing bug wrangler to properly assign the bug. solar, I'm only CCing you because I know you're interested in binary packages and have some valuable input. (In reply to comment #1) > We actually standardized on adding users in pkg_setup() for the simple fact > that binary packages are broken when adding the users in pkg_preinst(). > Basically because installing a binary package does not call the pkg_preinst() > function, so your suggested fix would break packages instead of the current way > which has an annoying side effect. > By binary package do you mean a package built with -b/-B/--buildpkg/--buildpkgonly? Those do run pkg_preinst() @ subsequent install. If not, could you give me an example of what you are referring to? > Additionally, base-system has nothing to do with this. Allowing bug wrangler to > properly assign the bug. I did, they assigned it to base-system. :) Examples of further issues with this are packages which require a user/group and then the src_install() step actually uses these users since the package's make install will chown/chgrp those files over to that user. There are many bugs in Bugzilla with that usage that have been fixed by moving the user creation to pkg_setup. Most mail setups, databases, and other packages suffer from this. Packages I know off the top of my head which would have this issue include, but are not limited to: dovecot, mysql, postgresql, postfix, dbus, hal, mythtv (In reply to comment #3) > Examples of further issues with this are packages which require a user/group > and then the src_install() step actually uses these users since the package's > make install will chown/chgrp those files over to that user. There are many > bugs in Bugzilla with that usage that have been fixed by moving the user > creation to pkg_setup. > Yes and that is why I stated: "I'd suggest any ebuilds not requiring the group/user to be installed in order to complete src_* functions..." Any ebuild that does the job of setting ownership/perms itself (rather than the make process) can do so after calling enew{group,user} from pkg_preinst(). Actually using pkg_setup is what devmanual suggests. I was about to modify ebuilds to fix pkg_preinstall to pkg_setup but found this bug. So what is the outcome? I'll CC qa may be they'll suggest us something. There is/was no outcome. just change the documentation and be done. both pkg_* functions are safe and really it's only a bug in the ebuild if it needs the user/group at compile time but created them in pkg_preinst rather than pkg_setup. *** Bug 237275 has been marked as a duplicate of this bug. *** (In reply to Peter Volkov from comment #5) > Actually using pkg_setup is what devmanual suggests. I was about to modify > ebuilds to fix pkg_preinstall to pkg_setup but found this bug. So what is > the outcome? I'll CC qa may be they'll suggest us something. Almost did the same thing with djbdns, five years later. First suggestion, https://devmanual.gentoo.org/ebuild-writing/functions/pkg_preinst/index.html: Adding users and groups. However, since pkg_preinst may be called after src_compile, pkg_setup is the more suitable location for user creation — see Users and Groups. Second suggestion, https://devmanual.gentoo.org/ebuild-writing/users-and-groups/index.html: Regardless of whether you are adding a group or a user, this should be performed in the pkg_setup function: pkg_setup is sandbox-safe, is called before the compile process so a build that requires the user to exist will have it, and is also called for both binary and source packages. It does say afterwards that you /may/ use pkg_preinst(), but it's bad practice to say something that may be wrong and count on the reader to keep reading long enough to get to the "but..." It seems like pkg_preinst is preferred, unless there is some necessity for pkg_setup? If so, we could list the reasons for preferring pkg_preinst and list the exceptions where pkg_setup is required. So should we re-assign this to the maintainers of the devmanual? Yeah, why is it assigned to you? Then if individual packages have problems, we can open bugs one-at-a-time and point people to the devmanual. Since this is assigned to the devmanual team pending a documentation update, and since user.eclass is now deprecated in favor of GLEP 81, I'm suggesting that we mark this whole thing obsolete. The devmanual is being updated for GLEP 81 and these problems will eventually fade away. GLEP81 is now in the devmanual, too. This problem will slowly go away as people migrate to acct-user packages. |
When an ebuild calls enew{group,user}() in pkg_setup(), the group/user will be added in the following erroneous scenarios: 1. group/user is added on the machine building the package, even when emerge is passed -B/--buildpkgonly. 2. group/user is added simply by using ebuild <ebuild> unpack. 3. group/user is added even if the build fails in src_* functions and is never installed. This is probably not desired behavior. I'd suggest any ebuilds not requiring the group/user to be installed in order to complete src_* functions should move enew{group,user}() calls to pkg_preinst() and the dev documentation should be changed to reflect this situation. List of packages with atleast one ebuild calling enew{group,user} in pkg_setup(): app-accessibility/festival app-admin/gkrellm app-admin/osiris app-admin/puppet app-admin/rmake app-admin/sabayon app-admin/system-tools-backends app-admin/tenshi app-antivirus/clamav app-backup/amanda app-backup/backuppc app-backup/bacula app-crypt/tpm-emulator app-crypt/trousers app-emulation/open-vm-tools app-emulation/virtualbox app-emulation/virtualbox-modules app-emulation/vmware-server-console app-i18n/dbskkd-cdb app-misc/beagle app-misc/dnetc app-misc/klive app-misc/screen app-mobilephone/kannel app-mobilephone/smstools app-mobilephone/sobexsrv dev-db/firebird dev-db/hsqldb dev-db/postgresql dev-db/xindice dev-libs/cyberjack dev-libs/opencryptoki dev-libs/openct dev-perl/mogilefs-server dev-php4/eaccelerator dev-php5/eaccelerator dev-util/buildbot dev-util/cvsd dev-util/eclipse-sdk dev-util/gitosis dev-util/gitosis-gentoo dev-util/monotone gnome-base/gdm mail-filter/anubis mail-filter/assp mail-filter/dk-milter mail-filter/dkim-milter mail-filter/dspam mail-filter/mimedefang mail-filter/policyd-weight mail-filter/postgrey mail-filter/qmail-scanner mail-filter/sid-milter mail-filter/simscan mail-filter/spamass-milter mail-filter/spamassassin-fuzzyocr mail-filter/sqlgrey mail-mta/mini-qmail mail-mta/netqmail mail-mta/nullmailer mail-mta/qmail-ldap mail-mta/sendmail mail-mta/xmail media-gfx/sane-backends media-libs/libgphoto2 media-sound/gnump3d media-sound/mpd media-sound/mserv media-sound/murmur media-sound/pulseaudio media-sound/rplay media-sound/slimserver media-sound/squeezecenter media-sound/teamspeak2-server-bin media-sound/timidity++ media-tv/gentoo-vdr-scripts media-tv/mythtv media-video/motion net-analyzer/FlowScan net-analyzer/flow-tools net-analyzer/jffnms net-analyzer/munin net-analyzer/nagios-core net-analyzer/nagios-nrpe net-analyzer/nagios-plugins net-analyzer/nagios-plugins-snmp net-analyzer/ndoutils net-analyzer/nepenthes net-analyzer/ntop net-analyzer/sancp net-analyzer/scanlogd net-analyzer/sguil-sensor net-analyzer/sguil-server net-analyzer/smokeping net-analyzer/snort net-analyzer/wireshark net-analyzer/zabbix net-analyzer/zabbix-agent net-analyzer/zabbix-server net-dialup/freeradius net-dialup/mgetty net-dialup/sendpage net-dns/bind net-dns/ddclient net-dns/djbdns net-dns/ldapdns net-dns/pdnsd net-fs/sfs net-ftp/frox net-ftp/ftpbase net-ftp/proftpd net-im/bitlbee net-irc/anope net-irc/atheme net-irc/charybdis net-irc/inspircd net-irc/irc-server net-irc/ircd-hybrid net-irc/ircservices net-irc/psybnc net-irc/rbot net-irc/srvx net-irc/unrealircd net-libs/courier-authlib net-mail/cyrus-imapd net-mail/dbmail net-mail/dot-forward net-mail/dovecot net-mail/mailbase net-mail/mailman net-mail/popa3d net-mail/vpopmail net-misc/dropbear net-misc/gofish net-misc/ices net-misc/italc net-misc/mdidentd net-misc/mediatomb net-misc/ndtpd net-misc/ntp net-misc/openntpd net-misc/radvd net-misc/ser net-misc/siproxd net-misc/spread net-misc/ssh net-misc/strongswan net-misc/stunnel net-misc/tor net-misc/udhcp net-nds/openldap net-nds/portmap net-p2p/entropy_rsa net-p2p/ghostwhitecrab net-print/cups net-proxy/havp net-proxy/ntlmaps net-proxy/oops net-proxy/polipo net-proxy/privoxy net-proxy/squid net-proxy/sshproxy net-proxy/ziproxy net-wireless/ipw3945d net-www/vdradmin-am sys-apps/einit sys-apps/hal sys-apps/man sys-apps/man-db sys-apps/mlocate sys-apps/paludis sys-apps/pmount sys-apps/rlocate sys-apps/slocate sys-apps/utempter sys-auth/policykit sys-auth/tcb sys-block/partimage sys-block/scsiadd sys-block/unieject sys-cluster/openais sys-freebsd/freebsd-pf sys-fs/owfs sys-libs/libutempter sys-power/nut sys-process/at sys-process/cronbase sys-process/fcron sys-process/vixie-cron www-apps/otrs www-apps/postfixadmin www-apps/rt www-apps/trac www-servers/fnord www-servers/gorg www-servers/lighttpd www-servers/nginx www-servers/ocsigen www-servers/resin www-servers/skunkweb www-servers/thttpd www-servers/tomcat x11-apps/xfs Reproducible: Always