The normal historical behavior for bacula is to install the bpipe-fd.so library with permissions 751. However, app-backup/bacula/bacula-9.6.3.ebuild installs it with permissions 750. This change causes no problems for Bacula, and does not appear to be OPERATIONALLY relevant to anything else. However, media-libs/mesa-19.3.5 fails inside meson_src_configure with a permissions error on /usr/lib64/bpipe-fd.so. I have tried this using both dev-util/meson-0.52.1 and dev-util/meson-0.54.2 and the behavior is unchanged. Why configuration of media-libs/mesa involves dev-util/meson trying to in some way inspect /usr/lib64/bpipe-fd.so is a completely unfathomable mystery to me, but there you have it. Bizarre as it may seem, meson is indeed attempting to fiddle with bpipe-fd.so. Reproducible: Always Steps to Reproduce: Install app-backup/bacula-9.6.3, if not already installed. USE=clientonly is sufficient. Verify that /usr/lib64/bpipe-fd.so is installed with mode 750 or 751. Try to rebuild media-libs/mesa. Watch it blow up inside meson_src_configure with a permissions error on bpipe-fd.so. Just 'ebuild configure' is sufficient, you don't have to actually try to compile. Change /usr/lib64/bpipe-fd.so to mode 755 and retry media-libs/mesa. Note that it now works with NO CHANGE except for read permission on that one library that it shouldn't reasonably even be looking at. babylon5:root:~:29 # emerge --info media-libs/mesa Portage 2.3.99 (python 3.7.7-final-0, default/linux/amd64/17.1/desktop, gcc-9.3.0, glibc-2.30-r8, 5.5.19-gentoo-babylon5 x86_64) ================================================================= System Settings ================================================================= System uname: Linux-5.5.19-gentoo-babylon5-x86_64-AMD_Phenom-tm-_II_X6_1090T_Processor-with-gentoo-2.6 KiB Mem: 16399056 total, 7810852 free KiB Swap: 0 total, 0 free Timestamp of repository gentoo: Thu, 28 May 2020 06:00:01 +0000 Head commit of repository gentoo: 2450abc1e7a2242f648eb9e16e75037ba63e7de5 Head commit of repository brother-overlay: 9ccba5d7c9fde9fdcb08e17695d25c3737089b71 Head commit of repository maggu2810-overlay: 33a9662e2c9e02daa43b9f583916effe2015735b Head commit of repository mysql: 4fc991d753db5c2c0c319acf981b4609c2ee64bb Head commit of repository palemoon: 1dc0fbff7298f25bab4dc8c106c0bd91a3145e6c Head commit of repository seeds: 301b6a8f2beb46e8e63da8f63f57a270b981edb0 sh bash 5.0_p17 ld GNU ld (Gentoo 2.33.1 p2) 2.33.1 app-shells/bash: 5.0_p17::gentoo dev-java/java-config: 2.2.0-r4::gentoo dev-lang/perl: 5.30.1::gentoo dev-lang/python: 2.7.18::gentoo, 3.7.7-r2::gentoo, 3.8.2-r2::gentoo dev-util/cmake: 3.17.2::gentoo dev-util/pkgconfig: 0.29.2::gentoo sys-apps/baselayout: 2.6-r1::gentoo sys-apps/openrc: 0.42.1::gentoo sys-apps/sandbox: 2.13::gentoo sys-devel/autoconf: 2.13-r1::gentoo, 2.69-r4::gentoo sys-devel/automake: 1.16.1-r1::gentoo sys-devel/binutils: 2.33.1-r1::gentoo sys-devel/gcc: 9.3.0::gentoo sys-devel/gcc-config: 2.2.1::gentoo sys-devel/libtool: 2.4.6-r6::gentoo sys-devel/make: 4.2.1-r4::gentoo sys-kernel/linux-headers: 5.6::gentoo (virtual/os-headers) sys-libs/glibc: 2.30-r8::gentoo Repositories: gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://minbar.caerllewys.net/gentoo-portage priority: -1000 sync-rsync-extra-opts: sync-rsync-verify-jobs: 1 sync-rsync-verify-metamanifest: yes sync-rsync-verify-max-age: 24 brother-overlay location: /var/db/repos/brother-overlay sync-type: git sync-uri: https://github.com/stefan-langenmaier/brother-overlay.git masters: gentoo gentoo-dev-alaric location: /var/lib/alaric masters: gentoo maggu2810-overlay location: /var/db/repos/maggu2810-overlay sync-type: git sync-uri: git://github.com/maggu2810/maggu2810-overlay.git masters: gentoo mysql location: /var/db/repos/mysql sync-type: git sync-uri: https://anongit.gentoo.org/git/proj/mysql.git masters: gentoo palemoon location: /var/db/repos/palemoon sync-type: git sync-uri: https://github.com/deu/palemoon-overlay.git masters: gentoo seeds location: /var/db/repos/seeds sync-type: git sync-uri: git://github.com/vonavi/seeds.git masters: gentoo ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=amdfam10 -O2 -pipe -mfpmath=sse -mcx16 -mpopcnt" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/config /usr/share/gnupg/qualified.txt /var/bind /var/lib/hsqldb" 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=amdfam10 -O2 -pipe -mfpmath=sse -mcx16 -mpopcnt" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--with-bdeps=y --verbose-conflicts --keep-going" ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://gentoo.osuosl.org http://www.gtlib.gatech.edu/pub/gentoo http://mirrors.cs.wmich.edu/gentoo http://distfiles.gentoo.org " LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="en_US en" MAKEOPTS="-j6" 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="3dnow 3dnowext X a52 aac acl acpi alsa amd64 bash-completion berkdb branding bzip2 cairo cdda cddb cdr cli crypt cups dbus dri dts dvd dvdr elogind emboss encode exif ffmpeg flac fltk fortran gdbm gif gpm gtk iconv icu id3tag imagemagick ipv6 java jpeg jpeg2k lcms ldap libnotify libtirpc mad mmx mmxext mng mp3 mp4 mpeg multilib mysql ncurses nls nptl nsplugin nvidia ogg opengl openmp opus pam pango pcre pcsc-lite pdf png policykit ppds qt5 readline sdl seccomp spell split-usr sse sse2 sse4 ssl startup-notification svg tcpd theora threads tiff tk tools truetype udev udisks unicode upower usb utils v4l v4l2 vdpau vorbis vpx wxwidgets x264 xattr xcb xml xpm xv xvid xvmc zlib" ABI_X86="64" ADA_TARGET="gnat_2018" ALSA_CARDS="emu10k1 hda-intel" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="3dnow 3dnowext mmx mmxext popcnt sse sse2 sse3 sse4a" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev keyboard mouse" KERNEL="linux" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-2" POSTGRES_TARGETS="postgres10 postgres11" PYTHON_SINGLE_TARGET="python3_7" PYTHON_TARGETS="python2_7 python3_7" RUBY_TARGETS="ruby24 ruby25" USERLAND="GNU" VIDEO_CARDS="nvidia v4l" 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_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS ================================================================= Package Settings ================================================================= media-libs/mesa-19.3.5::gentoo was built with the following: USE="X classic dri3 egl gallium gbm gles2 libglvnd llvm wayland -d3d9 -debug -gles1 -lm-sensors -opencl -osmesa -pax_kernel (-selinux) -test -unwind -vaapi -valgrind -vdpau -vulkan -vulkan-overlay -xa -xvmc" ABI_X86="(64) -32 (-x32)" VIDEO_CARDS="(-freedreno) -i915 -i965 -intel -iris (-lima) -nouveau (-panfrost) -r100 -r200 -r300 -r600 -radeon -radeonsi (-vc4) -virgl (-vivante) -vmware" FEATURES="usersync preserve-libs userpriv distlocks assume-digests binpkg-docompress ipc-sandbox config-protect-if-modified usersandbox binpkg-logs multilib-strict unknown-features-warn protect-owned qa-unresolved-soname-deps unmerge-logs merge-sync news sandbox network-sandbox pid-sandbox sfperms binpkg-dostrip strict ebuild-locks xattr unmerge-orphans userfetch parallel-fetch fixlafiles"
Created attachment 642394 [details] Build log
ALSO AFFECTS media-libs/gegl-0.4.22
Upon consideration, this bug should PROBABLY be revised to refer to dev-util/meson.
That is bizarre. Reassigning to the meson maintainer.
Please test this patch. https://github.com/floppym/meson/commit/13e9c88beadee28e3aedaf2abc919fcd5676cc18.patch
(In reply to Phil Stracchino (Unix Ronin) from comment #0) > The normal historical behavior for bacula is to install the bpipe-fd.so > library with permissions 751. However, > app-backup/bacula/bacula-9.6.3.ebuild installs it with permissions 750. > This change causes no problems for Bacula, and does not appear to be > OPERATIONALLY relevant to anything else. This seems like a bug in bacula; shared libraries in /usr/lib should always be installed with mode 0755. I'm not saying that meson is perfect here, but this is certainly very strange behavior on bacula's end.
Re-assigning this to the bacula maintainer due to the broken permissions. I don't care to track that issue myself. I created bug 726524 to address the meson issue.
(In reply to Mike Gilbert from comment #7) > Re-assigning this to the bacula maintainer due to the broken permissions. I > don't care to track that issue myself. > > I created bug 726524 to address the meson issue. I've verified that the library is installed on other platforms with the intended 751 permissions. 750 instead doesn't appear to cause any problems with Bacula. I don't actually see the mode as a problem for Bacula, except that it triggers the meson bug, which I was gradually narrowing in on through the course of my investigation. Thanks for narrowing that down to 'first library unreadable'.
(In reply to Phil Stracchino (Unix Ronin) from comment #8) > (In reply to Mike Gilbert from comment #7) > > Re-assigning this to the bacula maintainer due to the broken permissions. I > > don't care to track that issue myself. > > > > I created bug 726524 to address the meson issue. > > I've verified that the library is installed on other platforms with the > intended 751 permissions. 750 instead doesn't appear to cause any problems > with Bacula. I don't actually see the mode as a problem for Bacula, except > that it triggers the meson bug, which I was gradually narrowing in on > through the course of my investigation. > > Thanks for narrowing that down to 'first library unreadable'. Anyway, just checked the other libraries wich are built for bacula. They are all 755, only bpipe-fd.so is 750. Will look into it.
(In reply to Thomas Beierlein from comment #9) > (In reply to Phil Stracchino (Unix Ronin) from comment #8) > > (In reply to Mike Gilbert from comment #7) > > > Re-assigning this to the bacula maintainer due to the broken permissions. I > > > don't care to track that issue myself. > > > > > > I created bug 726524 to address the meson issue. > > > > I've verified that the library is installed on other platforms with the > > intended 751 permissions. 750 instead doesn't appear to cause any problems > > with Bacula. I don't actually see the mode as a problem for Bacula, except > > that it triggers the meson bug, which I was gradually narrowing in on > > through the course of my investigation. > > > > Thanks for narrowing that down to 'first library unreadable'. > > Anyway, just checked the other libraries wich are built for bacula. They are > all 755, only bpipe-fd.so is 750. Will look into it. The problem is indeed based on a bug in the bacula sources. All other bacula libraries uses INSTALL_LIB in Makefile.in which is set to '$(INSTALL) -m 755'. The build system for all plugins, with bpipe-fd the only one used at the moment, uses INSTALL_PROGRAM instead. These is set to '$(INSTALL) -m 750'. The difference to other distributions (having 751 instead of 750 for INSTALL_PROGRAMM) has still to be resolved. Phil can you please rely that findings to the bacula mailing list? Thanks. I will release a patched version shortly.
(In reply to Thomas Beierlein from comment #10) > > The difference to other distributions (having 751 instead of 750 for > INSTALL_PROGRAMM) has still to be resolved. > Baculas build system uses SBINPERMS for INSTALL_PROGRAM, which is set in configure.in to 750. So it seems other distros have modified that value or did a chown on the file.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=90d89edc09a124a7f1479e48257bc3f9ab9bf8f9 commit 90d89edc09a124a7f1479e48257bc3f9ab9bf8f9 Author: Thomas Beierlein <tomjbe@gentoo.org> AuthorDate: 2020-06-02 13:46:04 +0000 Commit: Thomas Beierlein <tomjbe@gentoo.org> CommitDate: 2020-06-02 13:46:04 +0000 app-backup/bacula: Fix installation of bpipe-fd.so Build system originally installs plugin library with mode 0750. Fixed in new revision 9.4.4-r3 and 9.6.3-r1. Reported-by: Phil Stracchino <phils@caerllewys.net> Closes: https://bugs.gentoo.org/725946 Package-Manager: Portage-2.3.100, Repoman-2.3.22 Signed-off-by: Thomas Beierlein <tomjbe@gentoo.org> app-backup/bacula/bacula-9.4.4-r3.ebuild | 429 +++++++++++++++++++++++++++++++ app-backup/bacula/bacula-9.6.3-r1.ebuild | 428 ++++++++++++++++++++++++++++++ 2 files changed, 857 insertions(+)
(In reply to Thomas Beierlein from comment #11) > Baculas build system uses SBINPERMS for INSTALL_PROGRAM, which is set in > configure.in to 750. So it seems other distros have modified that value or > did a chown on the file. It is very strange to install binaries in sbin with mode 0750. Nothing else does that. If a non-privileged user tries to run it, I would expect an error when the program tries to open some restricted file. There's no point in removing the ability to execute the program altogether.
(In reply to Mike Gilbert from comment #13) > (In reply to Thomas Beierlein from comment #11) > > Baculas build system uses SBINPERMS for INSTALL_PROGRAM, which is set in > > configure.in to 750. So it seems other distros have modified that value or > > did a chown on the file. > > It is very strange to install binaries in sbin with mode 0750. Nothing else > does that. > > If a non-privileged user tries to run it, I would expect an error when the > program tries to open some restricted file. There's no point in removing the > ability to execute the program altogether. In principle you are right. But that is not how it is implemented in bacula. They use the execute restrictions to separate the normal backup user and daily manager from the backup administrator. As bacula is a centralized backup system for enterprise backup I see some points in that decision. Looking into its scheme we see that the daily use management tools 'bconsole' 'bacula-tray' and 'bat' are 755 and therefore usable by everyone. All the management tools for recovery and fine tuning are reserved for the backup administrator by setting them 750 for user bacula group root. I spent the last week looking into other distros how they handle the permissions. There are quite some ones (debian, mint, ..) who just sets all that files to 755. While I see no problem for the /usr/sbin tools that permissions will also be used for all scripts in /usr/libexec/bacula to create, fine tune and/or destroy the backup database. Sure for postgresql and mysql you can (and should) set according passwords but for sqlite we do not have that choice. So I think for the moment it may be best to keep the actual solution. Btw, in all the years I cared for bacula it was the first time we had problems with access rights handling.
