[GH-ISSUE #3980] private-lib: can we mount instead of copy? #2490

Closed
opened 2026-05-05 09:10:21 -06:00 by gitea-mirror · 4 comments
Owner

Originally created by @smitsohu on GitHub (Feb 12, 2021).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3980

While in general private options copy files in the sandbox instead of mounting them, there are two exceptions to the rule:

  • private-tmp, which mounts a set of paths in the sandbox in order to provide essential sockets

  • private-lib, which currently employs a mix of copying and mounting: files are copied and directories are mounted

I would propose to move all of private-lib to mounts, mainly for performance reasons. For example it takes Firejail seconds to configure the sandbox firejail --noprofile --private-lib kcalc, even on a rather powerful notebook. On legacy hardware it can be ten seconds and more. Switching from copying to mounting accelerates sandbox setup by about an order of magnitude.

Resolving the inconsistency in the other direction, that is copy everything and mount nothing, is probably not going to work because of excessive RAM demand. Also it would slow down private-lib even more.

Originally created by @smitsohu on GitHub (Feb 12, 2021). Original GitHub issue: https://github.com/netblue30/firejail/issues/3980 While in general `private` options copy files in the sandbox instead of mounting them, there are two exceptions to the rule: - `private-tmp`, which mounts a set of paths in the sandbox in order to provide essential sockets - `private-lib`, which currently employs a mix of copying and mounting: files are copied and directories are mounted I would propose to move all of `private-lib` to mounts, mainly for performance reasons. For example it takes Firejail seconds to configure the sandbox `firejail --noprofile --private-lib kcalc`, even on a rather powerful notebook. On legacy hardware it can be ten seconds and more. Switching from copying to mounting accelerates sandbox setup by about an order of magnitude. Resolving the inconsistency in the other direction, that is copy everything and mount nothing, is probably not going to work because of excessive RAM demand. Also it would slow down `private-lib` even more.
Author
Owner

@reinerh commented on GitHub (Feb 12, 2021):

Mounting read-only?

<!-- gh-comment-id:778475215 --> @reinerh commented on GitHub (Feb 12, 2021): Mounting read-only?
Author
Owner

@smitsohu commented on GitHub (Feb 12, 2021):

@reinerh If we remove the read-only flag, it would tear holes in Firejail's basic read-only file system. So read-only would be best, I guess.

<!-- gh-comment-id:778484446 --> @smitsohu commented on GitHub (Feb 12, 2021): @reinerh If we remove the read-only flag, it would tear holes in Firejail's basic read-only file system. So read-only would be best, I guess.
Author
Owner

@reinerh commented on GitHub (Feb 12, 2021):

Okay, thanks. Just wanted to clarify if it gets mounted read-only.

<!-- gh-comment-id:778485758 --> @reinerh commented on GitHub (Feb 12, 2021): Okay, thanks. Just wanted to clarify if it gets mounted read-only.
Author
Owner

@netblue30 commented on GitHub (Feb 13, 2021):

Yes, I think we should clean it up and make it mount-only..

<!-- gh-comment-id:778622350 --> @netblue30 commented on GitHub (Feb 13, 2021): Yes, I think we should clean it up and make it mount-only..
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#2490
No description provided.