mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #1841] gnome-calculator's private-lib looks broken #1249
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#1249
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 26, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1841
On Arch Linux gnome-calculator's
private-libcondition is broken:This can be fixed by adding
gdk-pixbuf-2.0,gio,girepository-1.0,gvfs,libgconf-2.so.4,libgnutls.so.30,libproxy.so.1,librsvg-2.so.2,libxml2.so.2toprivate-libSo far so good, ready to do a PR or so I thought. On a whim, I wanted to confirm everything was working as expected by taking a quick glance from the app's perspective:
Brrr... Adding another few libs (libacl.so.1,libcap.so.2,libmpfr.so.6,libprocps.so.6,libreadline.so.7) seems to solve the
joinissue, but only when ignoringprivate-bin. Rather messy, but in a complex universe that's ofthen how the cookie crumbles... Now for my real question. Are there any documented guidelines on how long aprivate-libstring can be before it gets unworkable? I'll better hold off any short-term ('hey look what I found'-like) PR's on private-lib issues before seeking advice from the experts.Regards, I truly appreciate all the work being done in firejail. Including the very supportive athmosphere. No rush.
@Fred-Barclay commented on GitHub (Apr 1, 2018):
Hey @glitsj16 ! Sorry for the late reply.
Just to make sure I understand correctly,
gnome-calculatorworks when you've added thegdk-pixbuf-2.0,gio,girepository-1.0,gvfs,libgconf-2.so.4,libgnutls.so.30,libproxy.so.1,librsvg-2.so.2,libxml2.so.2line - but--joindoesn't work unless you add some additional libs, right?If so, that's alright and you don't have to worry about adding the extra libs to
private-lib. Generally speaking, ourprivate-options are only for running the particular program, not doing extra stuff like joining the sandbox. The reason being is that, as you saw, we'd have to add extra stuff to the private filters which decreases the overall sandbox tightness.private-binin particular would have to be modified beyond what's reasonable.If the above is correct, please send in a PR! I'll merge it unless someone else beats me to it. 😄
As far as I'm aware we don't have any guidelines for the maximum length of a line. As long as everything is actually needed in that line, then it's okay! But of course, for things like comments it's best to split them about the 80-character mark if feasible (just a personal preference).
@ghost commented on GitHub (Apr 1, 2018):
Hi @Fred-Barclay , no worries about your reply. Your understanding was fully correct, better than my own re-reading of the issue. 😄 Fixing private-lib for gnome-calculator is quite straightforward now I've got a few more clues as to how GTK apps work in that department. Filing a PR asap.
And thanks for explaining the rationale behind the
private-options. It all makes more sense now. Happy to read there's a common-sensical approach regarding max length etc., that's about the only sense I've got (on a good day). Enjoy the weekend, regards.