github-starred/firejail

Fork 0

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

[GH-ISSUE #3001] firejail --get and --put fail on filenames containing brackets #1879

New issue

Closed

opened 2026-05-05 08:32:57 -06:00 by gitea-mirror · 7 comments

gitea-mirror commented

2026-05-05 08:32:57 -06:00

Owner

Originally created by @JKjakay on GitHub (Oct 15, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3001

Hi, I am using firejail to sandbox firefox, and I love it! However, I have noticed a problem.

I'm running firefox with very restricted settings (--seccomp --private). So, in order to be able to retrieve downloaded files I use --get and --put to access the file within the sandbox. This works ok, except if the filename contains round brackets like "(" or ")", and maybe other special characters. I get an "invalid filename" error.

This happens with a filename like this:

foo(321).jpg

Escaping the illegal character wiith \ does not work. Using quotation marks also does not work: --get "/home/user/Downloads/foo(321).jpg"

Im using bash on Ubuntu 19.04. Regards JK

Originally created by @JKjakay on GitHub (Oct 15, 2019). Original GitHub issue: https://github.com/netblue30/firejail/issues/3001 Hi, I am using firejail to sandbox firefox, and I love it! However, I have noticed a problem. I'm running firefox with very restricted settings (--seccomp --private). So, in order to be able to retrieve downloaded files I use --get and --put to access the file within the sandbox. This works ok, except if the filename contains round brackets like "(" or ")", and maybe other special characters. I get an "invalid filename" error. This happens with a filename like this: foo(321).jpg Escaping the illegal character wiith \ does not work. Using quotation marks also does not work: --get "/home/user/Downloads/foo(321).jpg" Im using bash on Ubuntu 19.04. Regards JK

gitea-mirror

2026-05-05 08:32:57 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

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

Author

Owner

@JKjakay commented on GitHub (Oct 25, 2019):

Anybody got any ideas? I guess brackets may not work because there is no kind of filename expansion active with --put and --get. Probably for security, I think. But it still seems like a bug to me.

@JKjakay commented on GitHub (Oct 25, 2019): Anybody got any ideas? I guess brackets may not work because there is no kind of filename expansion active with --put and --get. Probably for security, I think. But it still seems like a bug to me.

gitea-mirror commented

2026-05-05 08:33:01 -06:00

Author

Owner

@smitsohu commented on GitHub (Nov 13, 2019):

I doubt you'll find a workaround, it is by design. Firejail rejects filenames if they contain certain characters.

@smitsohu commented on GitHub (Nov 13, 2019): I doubt you'll find a workaround, it is by design. Firejail rejects filenames if they contain certain characters.

gitea-mirror commented

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

Author

Owner

@JKjakay commented on GitHub (Nov 13, 2019):

Thank you for clarifying this. It should be mentioned somewhere in the documentation (which is, sadly, not good). If you can use a filename as an argument, you would expect it to behave according to Posix standards.

@JKjakay commented on GitHub (Nov 13, 2019): Thank you for clarifying this. It should be mentioned somewhere in the documentation (which is, sadly, not good). If you can use a filename as an argument, you would expect it to behave according to Posix standards.

gitea-mirror commented

2026-05-05 08:33:03 -06:00

Author

Owner

@kodo-pp commented on GitHub (Jan 16, 2020):

I agree with JKjakay with regard to this issue: the restrictions on the filenames don't seem to fit right with POSIX standards and, without being mentioned in the documentation (at least I couldn't find anything about them in the manual page man firejail), are quite surprising and counter-intuitive.

From the security viewpoint, I don't see any benefit of deliberately restricting the set of characters used in filenames in the context of --get, --put and --ls operations (which are supposed to work with any filenames). Firejail just has to access the specified file, which should not treat characters like brackets or exclamation sign in any special way. (I hope Firejail doesn't use any unquoted shell magic for these operations, does it?)

In fact, brackets are quite common in the filenames, especially of downloaded files, which often have names like some important file (2).zip. Managing such files is a typical use case (I guess, at least what --get/--put/--ls are designed for), so I see disallowing the work with some commonly used characters in filenames is a misfeature which harms the usability.

Also, I'm a bit surprised that there's been no action taken about this issue since November. Some discussion took place, but the issue wasn't resolved at all (it wasn't rejected or fixed in any way), so I wonder whether we can actually do something about it.

@kodo-pp commented on GitHub (Jan 16, 2020): I agree with JKjakay with regard to this issue: the restrictions on the filenames don't seem to fit right with POSIX standards and, without being mentioned in the documentation (at least I couldn't find anything about them in the manual page `man firejail`), are quite surprising and counter-intuitive. From the security viewpoint, I don't see any benefit of deliberately restricting the set of characters used in filenames in the context of `--get`, `--put` and `--ls` operations (which are supposed to work with **any** filenames). Firejail just has to access the specified file, which should not treat characters like brackets or exclamation sign in any special way. (I hope Firejail doesn't use any unquoted shell magic for these operations, does it?) In fact, brackets are quite common in the filenames, especially of downloaded files, which often have names like `some important file (2).zip`. Managing such files is a typical use case (I guess, at least what `--get`/`--put`/`--ls` are designed for), so I see disallowing the work with some commonly used characters in filenames is a misfeature which harms the usability. Also, I'm a bit surprised that there's been no action taken about this issue since November. Some discussion took place, but the issue wasn't resolved at all (it wasn't rejected or fixed in any way), so I wonder whether we can actually do something about it.

gitea-mirror commented

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

Author

Owner

@smitsohu commented on GitHub (Jan 17, 2020):

@netblue30 ?

I am not able to comment on all aspects, just would like to emphasize that current Firejail is POSIX compliant in this regard:

For a filename to be portable across implementations conforming to POSIX.1-2017, it shall consist only of the portable filename character set as defined in Portable Filename Character Set.

https://pubs.opengroup.org/onlinepubs/9699919799/

The set of characters from which portable filenames are constructed.
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 . _ -

The last three characters are the period, underscore, and hyphen-minus characters, respectively.

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_282

@smitsohu commented on GitHub (Jan 17, 2020): @netblue30 ? I am not able to comment on all aspects, just would like to emphasize that current Firejail is POSIX compliant in this regard: > For a filename to be portable across implementations conforming to POSIX.1-2017, it shall consist only of the portable filename character set as defined in Portable Filename Character Set. https://pubs.opengroup.org/onlinepubs/9699919799/ >The set of characters from which portable filenames are constructed. > A B C D E F G H I J K L M N O P Q R S T U V W X Y Z > a b c d e f g h i j k l m n o p q r s t u v w x y z > 0 1 2 3 4 5 6 7 8 9 . _ - > > The last three characters are the period, underscore, and hyphen-minus characters, respectively. https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_282

gitea-mirror commented

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

Author

Owner

@rusty-snake commented on GitHub (Feb 22, 2020):

@smitsohu this is fixed by #3156, right?

@rusty-snake commented on GitHub (Feb 22, 2020): @smitsohu this is fixed by #3156, right?

gitea-mirror commented

2026-05-05 08:33:07 -06:00

Author

Owner

@smitsohu commented on GitHub (Feb 24, 2020):

this is fixed by #3156, right?

Kind of. Let's close it for now.

@smitsohu commented on GitHub (Feb 24, 2020): > this is fixed by #3156, right? Kind of. Let's close it for now.

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

No description provided.

Rows
Columns