[GH-ISSUE #6889] firejail(1) man page does not say what is the current working directory inside the jail #3406

New issue

Open

opened 2026-05-05 09:58:14 -06:00 by gitea-mirror · 2 comments

gitea-mirror commented

2026-05-05 09:58:14 -06:00

Owner

Originally created by @vinc17fr on GitHub (Sep 3, 2025).
Original GitHub issue: https://github.com/netblue30/firejail/issues/6889

Description

The firejail(1) man page does not say what is the current working directory inside the jail. It seems to be that same directory unless it is no longer accessible under its old pathname, in which case the current working directory is changed to the (potentially new) home directory.

Steps to Reproduce

As root:

root@qaa:~# cd /opt
root@qaa:/opt# mkdir dir1
root@qaa:/opt# touch dir1/in-dir1 in-opt
root@qaa:/opt# firejail --noprofile --private=/opt/dir1
firejail version 0.9.76
[...]
root@qaa:/opt# ls
dir1  in-opt
root@qaa:/opt#

(same behavior without --noprofile), but if I start firejail from /root (the old home directory for root), I get:

root@qaa:~# ls
in-dir1

This behavior seems to be because opt is whitelisted by default (thus /opt is still valid as the current working directory), but the /root directory (pathname to be interpreted outside the jail) is no longer accessible.

Environment

Name/version/arch of the Linux kernel (uname -srm): Linux 6.16.3+deb14-amd64 x86_64
Name/version of the Linux distribution (e.g. "Ubuntu 20.04" or "Arch Linux"): Debian/unstable
Version of Firejail (firejail --version): 0.9.76

Originally created by @vinc17fr on GitHub (Sep 3, 2025). Original GitHub issue: https://github.com/netblue30/firejail/issues/6889 ### Description The `firejail(1)` man page does not say what is the current working directory inside the jail. It seems to be that same directory unless it is no longer accessible under its old pathname, in which case the current working directory is changed to the (potentially new) home directory. ### Steps to Reproduce As root: ``` root@qaa:~# cd /opt root@qaa:/opt# mkdir dir1 root@qaa:/opt# touch dir1/in-dir1 in-opt root@qaa:/opt# firejail --noprofile --private=/opt/dir1 firejail version 0.9.76 [...] root@qaa:/opt# ls dir1 in-opt root@qaa:/opt# ``` (same behavior without `--noprofile`), but if I start `firejail` from `/root` (the old home directory for root), I get: ``` root@qaa:~# ls in-dir1 ``` This behavior seems to be because `opt` is whitelisted by default (thus `/opt` is still valid as the current working directory), but the `/root` directory (pathname to be interpreted outside the jail) is no longer accessible. ### Environment - Name/version/arch of the Linux kernel (`uname -srm`): Linux 6.16.3+deb14-amd64 x86_64 - Name/version of the Linux distribution (e.g. "Ubuntu 20.04" or "Arch Linux"): Debian/unstable - Version of Firejail (`firejail --version`): 0.9.76

gitea-mirror added the

documentation

label 2026-05-05 09:58:14 -06:00

gitea-mirror commented

2026-05-05 09:58:16 -06:00

Author

Owner

@vinc17fr commented on GitHub (Sep 3, 2025):

Well, in addition to the documentation issue, I think that the behavior is incorrect. In addition to the above:

root@qaa:~# mkdir /root/subdir
root@qaa:~# mkdir /opt/dir1/subdir
root@qaa:~# touch /opt/dir1/subdir/in-dir1-subdir
root@qaa:~# cd /root/subdir
root@qaa:~/subdir# ls
root@qaa:~/subdir# firejail --noprofile --private=/opt/dir1
firejail version 0.9.76
[...]
root@qaa:~/subdir# ls
in-dir1-subdir
root@qaa:~/subdir#

This is unexpected because in the real file hierarchy, /root/subdir and /opt/dir1/subdir are unrelated directories.

@vinc17fr commented on GitHub (Sep 3, 2025): Well, in addition to the documentation issue, I think that the behavior is incorrect. In addition to the above: ``` root@qaa:~# mkdir /root/subdir root@qaa:~# mkdir /opt/dir1/subdir root@qaa:~# touch /opt/dir1/subdir/in-dir1-subdir root@qaa:~# cd /root/subdir root@qaa:~/subdir# ls root@qaa:~/subdir# firejail --noprofile --private=/opt/dir1 firejail version 0.9.76 [...] root@qaa:~/subdir# ls in-dir1-subdir root@qaa:~/subdir# ``` This is unexpected because in the real file hierarchy, `/root/subdir` and `/opt/dir1/subdir` are unrelated directories.

gitea-mirror commented

2026-05-05 09:58:16 -06:00

Author

Owner

@vinc17fr commented on GitHub (Sep 3, 2025):

And similarly, from one's home directory:

$ mkdir -p dir1/dir1
$ touch dir1/in-dir1
$ touch dir1/dir1/in-dir1-dir1
$ cd dir1
$ pwd
/home/vinc17/dir1
$ ls
dir1  in-dir1
$ firejail --noprofile --private=$HOME/dir1 sh
firejail version 0.9.76
[...]
$ pwd
/home/vinc17/dir1
$ ls
in-dir1-dir1

is also unexpected. If one was in a directory that corresponds to the new home or one of its subdirectories, I think that the pathname of the current working directory should be adapted so that one remains in the same directory (if still accessible).

@vinc17fr commented on GitHub (Sep 3, 2025): And similarly, from one's home directory: ``` $ mkdir -p dir1/dir1 $ touch dir1/in-dir1 $ touch dir1/dir1/in-dir1-dir1 $ cd dir1 $ pwd /home/vinc17/dir1 $ ls dir1 in-dir1 $ firejail --noprofile --private=$HOME/dir1 sh firejail version 0.9.76 [...] $ pwd /home/vinc17/dir1 $ ls in-dir1-dir1 ``` is also unexpected. If one was in a directory that corresponds to the new home or one of its subdirectories, I think that the pathname of the current working directory should be adapted so that one remains in the same directory (if still accessible).

gitea-mirror referenced this issue

2026-05-05 10:25:53 -06:00

[PR #3406] [MERGED] DBus filtering enhancements #4751

gitea-mirror referenced this issue

2026-05-05 10:49:13 -06:00

[PR #6451] [MERGED] docs: man: sort commands (firejail.1) #6021