mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #5727] build: --enable-private-lib is broken #3076
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#3076
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ghost on GitHub (Mar 10, 2023).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5727
After the recent changes introduced by
b689b69f6cI can't enableprivate-libsupport (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:
Now that private-lib support is
disabled by defaultI added the needed flag to enable support for it:Configure output confirms enabling private-lib support:
BUT, after building & installing I can't use private-lib and firejail reports support for it is
disabled:Not sure what's happening with
b689b69f6c(yet) but I wonder if someone can reproduce.FWIW, adding
-DHAVE_PRIVATE_LIBexplicitly to CFLAGSdoesfix enabling private-lib support. But that shouldn't be necessary if I understand things correctly...@rusty-snake commented on GitHub (Mar 10, 2023):
The flag is named
--disable-private-lib, isn't it?@ghost commented on GitHub (Mar 10, 2023):
Well, I'm confused somewhat by the commit. There's indeed a reference to
disable-private-lib:ddb685c1ec/configure (L1385)Also to
enable-private-lib:ddb685c1ec/configure (L3492-L3503)I've tried several variations but will do so again. Using
disable-private-libwould be a rather odd flag to do the opposite, no?@ghost commented on GitHub (Mar 10, 2023):
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!
@ghost commented on GitHub (Mar 13, 2023):
UPDATE
(1) Opened #5732 to fix generating private-lib entrees in our man pages. AFAICT only
man firejailandman firejail-profilesare affected.(2) Did some more digging and it looks like
87948b3ffefrom #5504 is involved. When reverting this commit in my PKGBUILD theenable-private-libflag works as expected without needing to explicitly add -DHAVE_PRIVATE_LIB explicitly to CFLAGS.@kmk3 Any thoughts on these latest observations?
@netblue30 commented on GitHub (Mar 13, 2023):
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:
@ghost commented on GitHub (Mar 13, 2023):
That's good to know, thanks.
Just to be clear, only problem is with
enablingprivate-lib. Once that is achieved (for me on Arch Linux via either adding to CFLAGS or via reverting87948b3ffe) it does work fine, just like it did beforeb689b69f6c. Thanks for looking at it once more.@ghost commented on GitHub (Mar 15, 2023):
UPDATE:
Looks like #5732 fixed this! Apologies for the noise, this is not a bug after all.