[GH-ISSUE #5333] `firejail --private=.` fails in some cases

gitea-mirror commented

2026-05-05 09:37:25 -06:00

Owner

Originally created by @ny4nk0 on GitHub (Aug 21, 2022).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5333

Description

firejail --private=. fails in some cases.

Consider this:

~/uwu$ tree --noreport
.
~/uwu$ LC_ALL=C firejail --noprofile --private=.
Parent pid 9498, child pid 9499
Child process initialized in 40.84 ms
~$ exit

Everything is fine here.

Now consider this:

~/uwu$ mkdir uwu
~/uwu$ tree --noreport
.
└── uwu
~/uwu$ LC_ALL=C firejail --noprofile --private=.
Parent pid 9606, child pid 9607
Child process initialized in 39.24 ms
~/uwu$ exit

firejail chdirs into ~/uwu inside the sandbox. Strange, isn't it?

Let's try with a file:

~/uwu$ rmdir uwu
~/uwu$ >uwu
~/uwu$ tree --noreport
.
└── uwu
~/uwu$ LC_ALL=C firejail --noprofile --private=.
Parent pid 9914, child pid 9915
Child process initialized in 39.08 ms
~$ exit

Okay, it seems fine. If ~/uwu inside the sandbox is a regular file, firejail detects that and does not chdir.

Now let's try something different:

~/uwu$ rm uwu
~/uwu$ ln -s /nonexistent uwu
~/uwu$ tree --noreport
.
└── uwu -> /nonexistent
~/uwu$ LC_ALL=C firejail --noprofile --private=.
Parent pid 10646, child pid 10647
Error: unable to enter private working directory: /home/nyanko/uwu
Error: proc 10646 cannot sync with peer: unexpected EOF
Peer 10647 unexpectedly exited with status 1

Oh no! No sandbox for you.

Environment

$ apt show firejail
Package: firejail
Version: 0.9.70-1~bpo11+1
[...]

Originally created by @ny4nk0 on GitHub (Aug 21, 2022). Original GitHub issue: https://github.com/netblue30/firejail/issues/5333 ### Description `firejail --private=.` fails in some cases. --- Consider this: ``` ~/uwu$ tree --noreport . ~/uwu$ LC_ALL=C firejail --noprofile --private=. Parent pid 9498, child pid 9499 Child process initialized in 40.84 ms ~$ exit ``` Everything is fine here. --- Now consider this: ``` ~/uwu$ mkdir uwu ~/uwu$ tree --noreport . └── uwu ~/uwu$ LC_ALL=C firejail --noprofile --private=. Parent pid 9606, child pid 9607 Child process initialized in 39.24 ms ~/uwu$ exit ``` `firejail` chdirs into `~/uwu` inside the sandbox. Strange, isn't it? --- Let's try with a file: ``` ~/uwu$ rmdir uwu ~/uwu$ >uwu ~/uwu$ tree --noreport . └── uwu ~/uwu$ LC_ALL=C firejail --noprofile --private=. Parent pid 9914, child pid 9915 Child process initialized in 39.08 ms ~$ exit ``` Okay, it seems fine. If `~/uwu` inside the sandbox is a regular file, `firejail` detects that and does not chdir. --- Now let's try something different: ``` ~/uwu$ rm uwu ~/uwu$ ln -s /nonexistent uwu ~/uwu$ tree --noreport . └── uwu -> /nonexistent ~/uwu$ LC_ALL=C firejail --noprofile --private=. Parent pid 10646, child pid 10647 Error: unable to enter private working directory: /home/nyanko/uwu Error: proc 10646 cannot sync with peer: unexpected EOF Peer 10647 unexpectedly exited with status 1 ``` Oh no! No sandbox for you. ### Environment ``` $ apt show firejail Package: firejail Version: 0.9.70-1~bpo11+1 [...] ```

gitea-mirror added the

needinfo

label 2026-05-05 09:37:25 -06:00

gitea-mirror commented

2026-05-05 09:37:28 -06:00

Author

Owner

@ny4nk0 commented on GitHub (Aug 21, 2022):

Also, check my DNS trips.

@ny4nk0 commented on GitHub (Aug 21, 2022): Also, check my DNS trips.

gitea-mirror commented

2026-05-05 09:37:28 -06:00

Author

Owner

@ghost commented on GitHub (Aug 22, 2022):

I cannot reproduce any of the firejail --private=. examples.

Also, check my DNS trips.

Can you rephrase or otherwise provide some context as to what you mean by this?

$ apt show firejail
Package: firejail
Version: 0.9.70-1~bpo11+1

Please see https://github.com/netblue30/firejail#ubuntu:
For Ubuntu 18.04+ and derivatives (such as Linux Mint), users are strongly advised to use the PPA.

@ghost commented on GitHub (Aug 22, 2022): I cannot reproduce any of the `firejail --private=.` examples. > Also, check my DNS trips. Can you rephrase or otherwise provide some context as to what you mean by this? > $ apt show firejail Package: firejail Version: 0.9.70-1~bpo11+1 Please see https://github.com/netblue30/firejail#ubuntu: For Ubuntu 18.04+ and derivatives (such as Linux Mint), users are strongly advised to use the [PPA](https://launchpad.net/~deki/+archive/ubuntu/firejail).

gitea-mirror commented

2026-05-05 09:37:30 -06:00

Author

Owner

@reinerh commented on GitHub (Aug 22, 2022):

$ apt show firejail
Package: firejail
Version: 0.9.70-1~bpo11+1

Please see https://github.com/netblue30/firejail#ubuntu: For Ubuntu 18.04+ and derivatives (such as Linux Mint), users are strongly advised to use the PPA.

Where did you see they are using Ubuntu/Mint? The version number indicates a backports package for Debian 11.

@reinerh commented on GitHub (Aug 22, 2022): > > $ apt show firejail > > Package: firejail > > Version: 0.9.70-1~bpo11+1 > > Please see https://github.com/netblue30/firejail#ubuntu: For Ubuntu 18.04+ and derivatives (such as Linux Mint), users are strongly advised to use the [PPA](https://launchpad.net/~deki/+archive/ubuntu/firejail). Where did you see they are using Ubuntu/Mint? The version number indicates a backports package for Debian 11.

gitea-mirror commented

2026-05-05 09:37:31 -06:00

Author

Owner

@ghost commented on GitHub (Aug 22, 2022):

Where did you see they are using Ubuntu/Mint? The version number indicates a backports package for Debian 11.

Oops, my bad. Apologies for the confusion. Regardless, I can't reproduce any of this. Can you?

@ghost commented on GitHub (Aug 22, 2022): > Where did you see they are using Ubuntu/Mint? The version number indicates a backports package for Debian 11. Oops, my bad. Apologies for the confusion. Regardless, I can't reproduce any of this. Can you?

gitea-mirror commented

2026-05-05 09:37:32 -06:00

Author

Owner

@reinerh commented on GitHub (Aug 22, 2022):

Yes, I can reproduce all the commands/behaviour above.
At first it didn't work because I was in a different directory (somewhere in /tmp), but then I tried with exactly the directories from @ny4nk0 and I observe the same behaviour.

But I think I can explain it.
It's related to $CWD, the current working directory.

when you are in ~/uwu, there is no ~/uwu/uwu and you run firejail --private=., there is no ~/uwu in the new private home, so it falls back to ~.
when you create a subdirectory uwu (so you have ~/uwu/uwu), running private firejail will keep you in ~/uwu inside the private home (as that was you current working directory befire invoking firejail).
when you instead create a file called uwu, chdir'ing to ~/uwu inside the private home also doesn't work, so you fall back to ~.
the fourth point is probably the failure that @ny4nk0 means in the title. and I can't explain why this happens. it seems that firejail doesn't handle broken symlinks when creating the private home and chdir'ing.

@reinerh commented on GitHub (Aug 22, 2022): Yes, I can reproduce all the commands/behaviour above. At first it didn't work because I was in a different directory (somewhere in /tmp), but then I tried with exactly the directories from @ny4nk0 and I observe the same behaviour. But I think I can explain it. It's related to $CWD, the current working directory. - when you are in ~/uwu, there is no ~/uwu/uwu and you run `firejail --private=.`, there is no ~/uwu in the new private home, so it falls back to ~. - when you create a subdirectory uwu (so you have ~/uwu/uwu), running private firejail will keep you in ~/uwu inside the private home (as that was you current working directory befire invoking firejail). - when you instead create a file called uwu, chdir'ing to ~/uwu inside the private home also doesn't work, so you fall back to ~. - the fourth point is probably the failure that @ny4nk0 means in the title. and I can't explain why this happens. it seems that firejail doesn't handle broken symlinks when creating the private home and chdir'ing.

gitea-mirror commented

2026-05-05 09:37:33 -06:00

Author

Owner

@ghost commented on GitHub (Aug 22, 2022):

Ow I was in ~/Downloads when trying to reproduce. Now I see my problem duh. Anyway, I always assumed/interpreted private=directory to be fed a full path (instead of . like here).

@ghost commented on GitHub (Aug 22, 2022): Ow I was in ~/Downloads when trying to reproduce. Now I see my problem duh. Anyway, I always assumed/interpreted private=directory to be fed a full path (instead of . like here).

gitea-mirror commented

2026-05-05 09:37:34 -06:00

Author

Owner

@ny4nk0 commented on GitHub (Aug 23, 2022):

@glitsj16

Also, check my DNS trips.

Can you rephrase or otherwise provide some context as to what you mean by this?

Oh, it's nothing. It's just a request to appreciate the subtle aestheticism of this issue's number. It starts with 53 (the port of the DNS protocol) and ends in three equal digits (trips). Besides, 53 is a prime, just like 5333. Isn't it fascinating? Maybe it is a message from God? If so, what is He trying to say?

@ny4nk0 commented on GitHub (Aug 23, 2022): @glitsj16 >> Also, check my DNS trips. > > Can you rephrase or otherwise provide some context as to what you mean by this? Oh, it's nothing. It's just a request to appreciate the subtle aestheticism of this issue's number. It starts with 53 (the port of the DNS protocol) and ends in three equal digits (trips). Besides, 53 is a prime, just like 5333. Isn't it fascinating? Maybe it is a message from God? If so, what is He trying to say?

gitea-mirror commented

2026-05-05 09:37:35 -06:00

Author

Owner

@ny4nk0 commented on GitHub (Aug 23, 2022):

@reinerh

It's related to $CWD, the current working directory.

Yes, $CWD is an important part of reproducing this.

@glitsj16

Anyway, I always assumed/interpreted private=directory to be fed a full path (instead of . like here).

Even if full paths are used, the issue still exists.

To reproduce this issue, these two things are required:

$CWD exists both inside and outside the sandbox;
inside the sandbox, $CWD points to a broken symlink.

@ny4nk0 commented on GitHub (Aug 23, 2022): @reinerh > It's related to $CWD, the current working directory. Yes, `$CWD` is an important part of reproducing this. @glitsj16 > Anyway, I always assumed/interpreted private=directory to be fed a full path (instead of . like here). Even if full paths are used, the issue still exists. To reproduce this issue, these two things are required: 1. `$CWD` exists both inside and outside the sandbox; 2. inside the sandbox, `$CWD` points to a broken symlink.

gitea-mirror commented

2026-05-05 09:37:35 -06:00

Author

Owner

@ny4nk0 commented on GitHub (Aug 23, 2022):

Also, I've come up with a (hopefully) new type of prime numbers.

5 is a prime, 53 is a prime, 5333 is a prime, but 533 is unfortunately not. But what if...

Let's define a nyanko prime as a nyanber that:

is a prime;
every prefix of its decimal representation is also a prime.

Here is a program that generates such numbers:

def prefixes(n):
    assert n >= 0
    s = str(n)
    for i in range(1, len(s)):
        yield int(s[:i])

def nyanko_primes(n):
    toseive = [False] * 2 + [True] * (n - 2)

    # sieve of Eratosthenes
    for i in range(n):
        if not toseive[i]:
            continue
        for j in range(i + 1, n):
            if j % i == 0:
                # j is not a prime :(
                toseive[j] = False

    # another seive
    for i in range(n):
        if not toseive[i]:
            continue
        for j in range(i + 1, n):
            for p in prefixes(j):
                if not toseive[p]:
                    # j is not special :(
                    toseive[j] = False
                    break

    return [i for i, is_prime in enumerate(toseive) if is_prime]

print(' '.join(str(np) for np in nyanko_primes(100000)))

Its output:

2 3 5 7 23 29 31 37 53 59 71 73 79 233 239 293 311 313 317 373 379 593 599 719 733 739 797 2333 2339 2393 2399 2939 3119 3137 3733 3739 3793 3797 5939 7193 7331 7333 7393 23333 23339 23399 23993 29399 31193 31379 37337 37339 37397 59393 59399 71933 73331 73939

If you want, we can rename such numbers to firejail primes, by the place of their discovery.

In any case, I need a research grant to research this topic in more detail.

@ny4nk0 commented on GitHub (Aug 23, 2022): Also, I've come up with a (hopefully) new type of prime numbers. 5 is a prime, 53 is a prime, 5333 is a prime, but 533 is unfortunately not. But what if... Let's define a nyanko prime as a nyanber that: 1. is a prime; 2. every prefix of its decimal representation is also a prime. Here is a program that generates such numbers: ```py def prefixes(n): assert n >= 0 s = str(n) for i in range(1, len(s)): yield int(s[:i]) def nyanko_primes(n): toseive = [False] * 2 + [True] * (n - 2) # sieve of Eratosthenes for i in range(n): if not toseive[i]: continue for j in range(i + 1, n): if j % i == 0: # j is not a prime :( toseive[j] = False # another seive for i in range(n): if not toseive[i]: continue for j in range(i + 1, n): for p in prefixes(j): if not toseive[p]: # j is not special :( toseive[j] = False break return [i for i, is_prime in enumerate(toseive) if is_prime] print(' '.join(str(np) for np in nyanko_primes(100000))) ``` Its output: ``` 2 3 5 7 23 29 31 37 53 59 71 73 79 233 239 293 311 313 317 373 379 593 599 719 733 739 797 2333 2339 2393 2399 2939 3119 3137 3733 3739 3793 3797 5939 7193 7331 7333 7393 23333 23339 23399 23993 29399 31193 31379 37337 37339 37397 59393 59399 71933 73331 73939 ``` If you want, we can rename such numbers to firejail primes, by the place of their discovery. In any case, I need a research grant to research this topic in more detail.

Rows
Columns

[GH-ISSUE #5333] firejail --private=. fails in some cases #2961

Description

Environment

[GH-ISSUE #5333] `firejail --private=.` fails in some cases #2961