github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #1082] Why are root-owned files owned by uid 65534 inside sandboxes? #737

New issue

Closed

opened 2026-05-05 06:32:51 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-05-05 06:32:51 -06:00

Owner

Originally created by @zackw on GitHub (Jan 31, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1082

All files that are owned by root in the outer environment are owned by uid+gid 65534 ("nobody") inside sandboxes, and there doesn't seem to be any way to turn this off. Why is this done? It doesn't seem to be necessary, and it actually screws up some applications' sanity checks -- for instance, Xlib will complain about /tmp/.X11-unix not being owned by root.

Originally created by @zackw on GitHub (Jan 31, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1082 All files that are owned by root in the outer environment are owned by uid+gid 65534 ("nobody") inside sandboxes, and there doesn't seem to be any way to turn this off. Why is this done? It doesn't seem to be necessary, and it actually screws up some applications' sanity checks -- for instance, Xlib will complain about `/tmp/.X11-unix` not being owned by root.

gitea-mirror

2026-05-05 06:32:51 -06:00

closed this issue
added the
information_old
label

gitea-mirror commented

2026-05-05 06:33:00 -06:00

Author

Owner

@valoq commented on GitHub (Jan 31, 2017):

If available firejail uses user namespaces to run in an environment without root available to increase security. 65534 ("nobody") it the substitute for all users not present in that namespace.

@valoq commented on GitHub (Jan 31, 2017): If available firejail uses user namespaces to run in an environment without root available to increase security. 65534 ("nobody") it the substitute for all users not present in that namespace.

gitea-mirror commented

2026-05-05 06:33:02 -06:00

Author

Owner

@zackw commented on GitHub (Jan 31, 2017):

Can you please explain why omitting uid 0 from a user namespace increases its security (keep in mind that nothing can become uid 0 in the presence of NONEWPRIVS)? As I said, this actually screws up some programs' sanity checks, and I suspect it makes it easier for the affected files to accidentally get written to.

@zackw commented on GitHub (Jan 31, 2017): Can you please explain why omitting uid 0 from a user namespace _increases_ its security (keep in mind that nothing can _become_ uid 0 in the presence of NONEWPRIVS)? As I said, this actually screws up some programs' sanity checks, and I suspect it makes it _easier_ for the affected files to accidentally get written to.

gitea-mirror commented

2026-05-05 06:33:04 -06:00

Author

Owner

@netblue30 commented on GitHub (Feb 1, 2017):

In case NONEWPRIVS fails because of some bug in the kernel, an exploit will get stuck not finding uid 0 - at least that's may thinking in this moment.

Xlib will complain about /tmp/.X11-unix not being owned by root.

It is possible some programs will complain.

@netblue30 commented on GitHub (Feb 1, 2017): In case NONEWPRIVS fails because of some bug in the kernel, an exploit will get stuck not finding uid 0 - at least that's may thinking in this moment. > Xlib will complain about /tmp/.X11-unix not being owned by root. It is possible some programs will complain.

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#737

No description provided.

Rows
Columns