I have tracked down the issue that bug 520064 and bug 542256 were about. It turns out to be nothing to do with the stage3 used. net-mail/mailbase uses enewuser() from the 'user' eclass to create the "mail" and "postmaster" users, and for both of these it specifies "/var/spool/mail" as the home directory. Later on, "useradd" is called with the "-r" switch, which automatically creates this directory if it doesn't already exist, using default permissions. Because mailbase wants different permissions, it then complains about this. This behaviour occurs *only* if the 'mail' and 'postmaster' users/groups don't already exist, and if the /var/spool/mail directory doesn't exist. This is probably why people have been unable to reproduce the problem up until now, and why people thought it might be a problem with the stage3 - as it normally only occurs the first time. Using the below steps I can reproduce the issue every time. Steps to reproduce: 1. Start with net-mail/mailbase unmerged, or unmerge it: emerge --unmerge net-mail/mailbase 2. Delete the 'mail' and 'postmaster' users/groups, if they exist: userdel -r mail userdel postmaster 3. Emerge net-mail/mailbase: emerge --ask --oneshot net-mail/mailbase Expected results: /var/spool/mail is created with the proper permissions - root:mail, 03755. Actual results: /var/spool/mail is created as mail:root, 0755 and net-mail/mailbase complains about this: > * Your /var/spool/mail/ directory permissions differ from > * those which mailbase wants to set it to (03775). > * If you did not change them on purpose, consider running: > * > * chown root:mail /var/spool/mail/ > * chmod 03775 /var/spool/mail/ emerge --info: Portage 2.3.3 (python 2.7.12-final-0, default/linux/amd64/13.0, gcc-4.9.4, glibc-2.23-r3, 4.7.0-gentoo-mynouveau x86_64) ================================================================= System uname: Linux-4.7.0-gentoo-mynouveau-x86_64-Intel-R-_Core-TM-_i7-5820K_CPU_@_3.30GHz-with-gentoo-2.3 KiB Mem: 32925664 total, 11490448 free KiB Swap: 8191996 total, 8164176 free Timestamp of repository gentoo: Tue, 21 Mar 2017 12:00:01 +0000 sh bash 4.3_p48-r1 ld GNU ld (Gentoo 2.26.1 p1.0) 2.26.1 app-shells/bash: 4.3_p48-r1::gentoo dev-java/java-config: 2.2.0-r3::gentoo dev-lang/perl: 5.22.3_rc4::gentoo dev-lang/python: 2.7.12::gentoo, 3.4.5::gentoo dev-util/cmake: 3.7.2::gentoo dev-util/pkgconfig: 0.28-r2::gentoo sys-apps/baselayout: 2.3::gentoo sys-apps/openrc: 0.23.2::gentoo sys-apps/sandbox: 2.10-r3::gentoo sys-devel/autoconf: 2.13::gentoo, 2.69::gentoo sys-devel/automake: 1.11.6-r1::gentoo, 1.15::gentoo sys-devel/binutils: 2.26.1::gentoo sys-devel/gcc: 4.9.4::gentoo sys-devel/gcc-config: 1.7.3::gentoo sys-devel/libtool: 2.4.6-r3::gentoo sys-devel/make: 4.2.1::gentoo sys-kernel/linux-headers: 4.4::gentoo (virtual/os-headers) sys-libs/glibc: 2.23-r3::gentoo Repositories: gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://rsync.gentoo.org/gentoo-portage priority: -1000 sph-local location: /opt/portage-overlay masters: gentoo priority: 0 abendbrot location: /var/lib/layman/abendbrot masters: gentoo priority: 50 gambas-overlay location: /var/lib/layman/gambas-overlay masters: gentoo priority: 50 steam-overlay location: /var/lib/layman/steam-overlay masters: gentoo priority: 50 x11 location: /var/lib/layman/x11 masters: gentoo priority: 50 ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/lib64/avfs/extfs /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=native -O2 -pipe" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--ask-enter-invalid --autounmask-keep-masks y" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="https://ftp-stud.hs-esslingen.de/pub/Mirrors/gentoo/" LANG="en_GB.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j13" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" USE="X a52 aac aacplus acl acpi alsa amd64 amr berkdb bluray bzip2 cairo cdda cddb cdio cdparanoia cli cracklib crypt cups cxx dbus dri dts dvd flac fluidsynth fontconfig fortran gdbm gpm gtk iconv ipv6 jpeg libnotify lzma mad mmx modplug modules mp3 mtp multilib ncurses nls nptl ogg opengl openmp pam pcre png qt3support qt5 readline seccomp session sound sse sse2 ssl startup-notification tcl tcpd theora tk truetype unicode v4l vdpau vim-syntax vorbis xattr xv xvmc zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx avx2 fma3 mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="libinput keyboard mouse" KERNEL="linux" L10N="en en_GB" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en en_GB" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_4" QEMU_SOFTMMU_TARGETS="x86_64 arm i386 mips mipsel ppc sparc" QEMU_USER_TARGETS="aarch64 alpha arm i386 m68k mips mipsel ppc sparc x86_64" RUBY_TARGETS="ruby21" USERLAND="GNU" VIDEO_CARDS="nouveau" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
To be clear, when I said: > Later on, "useradd" is called with the "-r" switch... I meant: > In the enewuser() function in the 'user' eclass, "useradd" is called with the "-r" switch... My apologies for being unclear.
Other bugs that reference this issue: bug 591686, bug 532990.
By the way, I got the "-r" switch description of useradd wrong - that doesn't create the directory, it create it as a system account - my mistake. That actually makes this weirder because I assumed the problem at first was that useradd was creating the directory outside of the sandbox, and the permissions in the sandbox weren't kept, but I don't see where in enewuser() it would be making the directory. Thus, I'm no longer entirely sure what's going on, but do know that the above series of steps - including the deleting of the users and directory - still triggers the issue every time. Hopefully somebody else can work it out!
(and, of course, I meant 03775 instead of 03755. Hopefully that was obvious!)
Never mind, I see - enewuser() actually creates it right at the end of the function: > einfo " - Creating ${ehome} in ${ROOT}" > mkdir -p "${ROOT}/${ehome}" > chown "${euser}" "${ROOT}/${ehome}" > chmod 755 "${ROOT}/${ehome}" I initially missed it because it happens after the user is added, and I thought it was done at that point!
Just wanted to clarify - when I said "Never mind" in my previous reply, that was actually just referring to my confusion in comment 3. The bug, and my explanation for why it occurs in the original comment, still applies. I did make a few mistakes in the original post, though, so here's a newer, fixed version of the post I should have made: ===== I have tracked down the issue that bug 520064 and bug 542256 were about. It turns out to be nothing to do with the stage3 used. During its pkg_setup phase, net-mail/mailbase uses enewuser() from the 'user' eclass to create the "mail" and "postmaster" users, and for both of these it specifies "/var/spool/mail" as the home directory. The first time enewuser() is called, it creates the directory if it doesn't already exist, using default permissions. In src_install, net-mail/mailbase then uses the "fperms" command to change /var/spool/mail 's permissions to 03775. However, Later on, "useradd" is called with the "-r" switch, which automatically creates this directory if it doesn't already exist, using default permissions. Because mailbase wants different permissions, it then complains about this. This behaviour occurs *only* if the 'mail' and 'postmaster' users/groups don't already exist, and if the /var/spool/mail directory doesn't exist. This is probably why people have been unable to reproduce the problem up until now, and why people thought it might be a problem with the stage3 - as it normally only occurs the first time. Using the below steps I can reproduce the issue every time. Steps to reproduce: 1. Start with net-mail/mailbase unmerged, or unmerge it: emerge --unmerge net-mail/mailbase 2. Delete the 'mail' and 'postmaster' users/groups, if they exist: userdel -r mail userdel postmaster 3. Emerge net-mail/mailbase: emerge --ask --oneshot net-mail/mailbase Expected results: /var/spool/mail is created with the proper permissions - root:mail, 03755. Actual results: /var/spool/mail is created as mail:root, 0755 and net-mail/mailbase complains about this: > * Your /var/spool/mail/ directory permissions differ from > * those which mailbase wants to set it to (03775). > * If you did not change them on purpose, consider running: > * > * chown root:mail /var/spool/mail/ > * chmod 03775 /var/spool/mail/
Pressed RETURN too soon, sorry. I'm not sure how to delete Bugzilla replies, so here's the post again actually completed: ===== I have tracked down the issue that bug 520064 and bug 542256 were about. It turns out to be nothing to do with the stage3 used. During its pkg_setup phase, net-mail/mailbase uses enewuser() from the 'user' eclass to create the "mail" and "postmaster" users, and for both of these it specifies "/var/spool/mail" as the home directory. The first time enewuser() is called, it creates the directory if it doesn't already exist, using default permissions. It does this using the ${ROOT} directory. In src_install, net-mail/mailbase then uses the "fperms" command to change /var/spool/mail 's permissions to 03775. However, fperms does this in ${D}, so this does not affect the directory that was already created in ${ROOT}. The install then copies over the files from the install, making the directories if they don't already exist. However, /var/spool/mail is guaranteed to already exist thanks to the enewuser() creation above, and its permissions aren't changed. After the install, in pkg_postinst, the permissions are checked and found to be incorrect. Because mailbase wants different permissions, it then complains about this. This behaviour occurs *only* if the 'mail' and 'postmaster' users/groups don't already exist, and if the /var/spool/mail directory doesn't exist. This is probably why people have been unable to reproduce the problem up until now, and why people thought it might be a problem with the stage3 - as it normally only occurs the first time. Using the below steps I can reproduce the issue every time. Steps to reproduce: 1. Start with net-mail/mailbase unmerged, or unmerge it: emerge --unmerge net-mail/mailbase 2. Delete the 'mail' and 'postmaster' users/groups, if they exist: userdel -r mail userdel postmaster 3. Emerge net-mail/mailbase: emerge --ask --oneshot net-mail/mailbase Expected results: /var/spool/mail is created with the proper permissions - root:mail, 03775. Actual results: /var/spool/mail is created as mail:root, 0755 and net-mail/mailbase complains about this: > * Your /var/spool/mail/ directory permissions differ from > * those which mailbase wants to set it to (03775). > * If you did not change them on purpose, consider running: > * > * chown root:mail /var/spool/mail/ > * chmod 03775 /var/spool/mail/
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3b8f34badbdf4008f9d92db08d49b1e6ead27868 commit 3b8f34badbdf4008f9d92db08d49b1e6ead27868 Author: Eray Aslan <eras@gentoo.org> AuthorDate: 2018-04-04 14:03:38 +0000 Commit: Eray Aslan <eras@gentoo.org> CommitDate: 2018-04-04 14:03:38 +0000 net-mail/mailbase: fix mail spool permissions on first install Closes: https://bugs.gentoo.org/614396 Package-Manager: Portage-2.3.28, Repoman-2.3.9 net-mail/mailbase/mailbase-1.2.ebuild | 65 +++++++++++++++++++++++++++++++++++ 1 file changed, 65 insertions(+)
