build: --enable-private-lib is broken

[glitsj16]

After the recent changes introduced by b689b69 I can't enable private-lib support (without a dirty hack as shown below).

OS: Arch Linux (fully updated)
firejail built from git (kept on par with master)

For quite a while I configure/build with AppArmor and GCC analyzer support:

./configure --prefix=/usr --enable-analyzer --enable-apparmor
make

Now that private-lib support is disabled by default I added the needed flag to enable support for it:

./configure --prefix=/usr --enable-analyzer --enable-apparmor --enable-private-lib
make

Configure output confirms enabling private-lib support:

Compile options:
   CC: gcc
   CFLAGS: -march=native -O2 -pipe -fno-plt -fexceptions         -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security         -fstack-clash-protection -fcf-protection
   LDFLAGS: -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now
   EXTRA_CFLAGS:  -fstack-clash-protection -fstack-protector-strong -fanalyzer -Wno-analyzer-malloc-leak 
   EXTRA_LDFLAGS: 
   LIBS:  -lapparmor 
   fatal warnings: 
   gcov instrumentation: 
   install as a SUID executable: -DHAVE_SUID
   install contrib scripts: yes
   prefix: /usr
   sysconfdir: /etc
   Spectre compiler patch: yes

Features:
   allow tmpfs as regular user: -DHAVE_USERTMPFS
   always enforce filters: 
   apparmor: -DHAVE_APPARMOR
   busybox workaround: no
   chroot: -DHAVE_CHROOT
   DBUS proxy support: -DHAVE_DBUSPROXY
   disable user profiles: 
   enable --output logging: -DHAVE_OUTPUT
   file transfer support: -DHAVE_FILE_TRANSFER
   firetunnel support: 
   global config: -DHAVE_GLOBALCFG
   IDS support: 
   LTS: 
   manpage support: -DHAVE_MAN
   network: -DHAVE_NETWORK
   overlayfs support: 
   private home support: -DHAVE_PRIVATE_HOME
   private lib support: -DHAVE_PRIVATE_LIB
   SELinux labeling support: 
   user namespace: -DHAVE_USERNS
   X11 sandboxing support: -DHAVE_X11

BUT, after building & installing I can't use private-lib and firejail reports support for it is disabled:

$ firejail --version
firejail version 0.9.73

Compile time support:
	- always force nonewprivs support is disabled
	- AppArmor support is enabled
	- AppImage support is enabled
	- chroot support is enabled
	- D-BUS proxy support is enabled
	- file transfer support is enabled
	- firetunnel support is disabled
	- IDS support is disabled
	- networking support is enabled
	- output logging is enabled
	- overlayfs support is disabled
	- private-home support is enabled
	- private-lib support is disabled
	- private-cache and tmpfs as user enabled
	- SELinux support is disabled
	- user namespace support is enabled
	- X11 sandboxing support is enabled

Not sure what's happening with b689b69 (yet) but I wonder if someone can reproduce.

FWIW, adding -DHAVE_PRIVATE_LIB explicitly to CFLAGS does fix enabling private-lib support. But that shouldn't be necessary if I understand things correctly...

[rusty-snake]

The flag is named --disable-private-lib, isn't it?

[glitsj16]

The flag is named --disable-private-lib, isn't it?

Well, I'm confused somewhat by the commit. There's indeed a reference to disable-private-lib:

firejail/configure

Line 1385 in ddb685c

--disable-private-lib disable private lib feature

Also to enable-private-lib:

firejail/configure

Lines 3492 to 3503 in ddb685c

	# Check whether --enable-private-lib was given.
	if test "${enable_private_lib+set}" = set; then :
	enableval=$enable_private_lib;
	fi
	if test "x$enable_private_lib" = "xyes"; then :
	HAVE_PRIVATE_LIB="-DHAVE_PRIVATE_LIB"
	fi

I've tried several variations but will do so again. Using disable-private-lib would be a rather odd flag to do the opposite, no?

[glitsj16]

Oh, one more detail. I always build with makechrootpkg or the like on Arch Linux. That should avoid any interference from existing firejailed commands (like makepkg for example). My script hasn't changed for as long as private-lib was supported by default. So when I noticed the commit that turned this around I made an edit to it. And things started to break... Anyway, thanks for your input!

[glitsj16]

UPDATE

(1) Opened #5732 to fix generating private-lib entrees in our man pages. AFAICT only man firejail and man firejail-profiles are affected.

(2) Did some more digging and it looks like 87948b3 from #5504 is involved. When reverting this commit in my PKGBUILD the enable-private-lib flag works as expected without needing to explicitly add -DHAVE_PRIVATE_LIB explicitly to CFLAGS.

@kmk3 Any thoughts on these latest observations?

[netblue30]

I got it here. I'll bring in a fix today.

Later: Sorry for the previous message, I think is working fine on Debian stable:

$ firejail --private-bin=bash,ls,cd,pwd,cat --private-lib
Reading profile /etc/firejail/default.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-programs.inc

** Note: you can use --noprofile to disable default.profile **

Parent pid 39362, child pid 39363
4 programs installed in 12.27 ms
Standard C library installed in 3.16 ms
Firejail libraries installed in 2.30 ms
Program libraries installed in 10.62 ms
Installed 32 libraries and 2 directories
Child process initialized in 145.48 ms
netblue@debian:~/github/firejail$ ls /bin
bash  cat  ls  pwd
netblue@debian:~/github/firejail$ ls /lib
firejail  ld-linux-x86-64.so.2	locale	x86_64-linux-gnu
netblue@debian:~/github/firejail$ 

[glitsj16]

Later: Sorry for the previous message, I think is working fine on Debian stable

That's good to know, thanks.

Just to be clear, only problem is with enabling private-lib. Once that is achieved (for me on Arch Linux via either adding to CFLAGS or via reverting 87948b3) it does work fine, just like it did before b689b69. Thanks for looking at it once more.

[glitsj16]

UPDATE:

Looks like #5732 fixed this! Apologies for the noise, this is not a bug after all.