[GH-ISSUE #5179] kodi: can access non-media paths

gitea-mirror commented

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

Owner

Originally created by @tomasz-c on GitHub (Jun 7, 2022).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5179

Description

I noticed that the kodi profile for firejail 0.9.68 does not seem to work.

From the file manager in Kodi I can browse all directories, drives (not just those defined in the profile) and delete data from them (if Linux permissions allow it). Surely in some previous version this worked correctly.

Steps to Reproduce

run Kodi:
firejail --profile=/etc/firejail/kodi.profile kodi
go to Settings
run the file manager
try to browse all directories or delete files

Expected behavior

No ability to view or delete files outside the media folders defined in the profile.

Actual behavior

Possible to view and delete files outside the media folders defined in the profile.

Behavior without a profile

In terms of viewing and deleting files, the same as with a profile.

Environment

Linux distribution: Arch Linux
Firejail version: 0.9.68
Kodi version: 19.4

Originally created by @tomasz-c on GitHub (Jun 7, 2022). Original GitHub issue: https://github.com/netblue30/firejail/issues/5179 ### Description I noticed that the kodi profile for firejail 0.9.68 does not seem to work. From the file manager in Kodi I can browse all directories, drives (not just those defined in the profile) and delete data from them (if Linux permissions allow it). Surely in some previous version this worked correctly. ### Steps to Reproduce 1. run Kodi: `firejail --profile=/etc/firejail/kodi.profile kodi` 2. go to Settings 3. run the file manager 4. try to browse all directories or delete files ### Expected behavior No ability to view or delete files outside the media folders defined in the profile. ### Actual behavior Possible to view and delete files outside the media folders defined in the profile. ### Behavior without a profile In terms of viewing and deleting files, the same as with a profile. ### Environment - Linux distribution: Arch Linux - Firejail version: 0.9.68 - Kodi version: 19.4

gitea-mirror

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

closed this issue
added the
wontfix
label

gitea-mirror commented

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

Author

Owner

@rusty-snake commented on GitHub (Jun 7, 2022):

Second note that kodi.profile isn't whitelisting profile and does not set disable-mnt. So if you can access /mnt/foo/bar or ~/Downloads/frogs.png this is expected.

@rusty-snake commented on GitHub (Jun 7, 2022): > Second note that kodi.profile isn't whitelisting profile and does not set `disable-mnt`. So if you can access `/mnt/foo/bar` or `~/Downloads/frogs.png` this is expected.

gitea-mirror commented

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

Author

Owner

@tomasz-c commented on GitHub (Jun 7, 2022):

@rusty-snake
But I understand that if I have home mounted from a separate partition it doesn't matter?
I can also view the contents of /etc and this should not work?

@tomasz-c commented on GitHub (Jun 7, 2022): @rusty-snake But I understand that if I have home mounted from a separate partition it doesn't matter? I can also view the contents of /etc and this should not work?

gitea-mirror commented

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

Author

Owner

@rusty-snake commented on GitHub (Jun 7, 2022):

But I understand that if I have home mounted from a separate partition it doesn't matter?

I don't understand what you mean.

I can also view the contents of /etc and this should not work?

Where is /etc restricted (via whitelisting) in kodi.profile? _{answer: nowhere}

@rusty-snake commented on GitHub (Jun 7, 2022): > But I understand that if I have home mounted from a separate partition it doesn't matter? I don't understand what you mean. > I can also view the contents of /etc and this should not work? Where is `/etc` restricted (via whitelisting) in kodi.profile? <sub>answer: nowhere</sub>

gitea-mirror commented

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

Author

Owner

@tomasz-c commented on GitHub (Jun 7, 2022):

I don't understand what you mean.

Mounting /dev/sdXY to /home
I don't know how disable-mnt works, but from what I found it should only block access to /mnt

Where is /etc restricted (via whitelisting) in kodi.profile? answer: nowhere

This is a bit unintuitive to me, as I always thought whitelists were for unlocking :)

I don't know firejail profile configuration well, I reported this bug because this behavior in my opinion is dangerous: allowing kodi to access everything as well as delete files. Because of the support for plugins that don't necessarily pass any security audits and can even be potentially malicious (I know of one such case).
I know that in the past firejail with the default kodi profile didn't allow this, so if it does now I consider it a bug, but if this behavior is expected then somehow I will understand it and close the bug :)

@tomasz-c commented on GitHub (Jun 7, 2022): > I don't understand what you mean. Mounting /dev/sdXY to /home I don't know how `disable-mnt` works, but from what I found it should only block access to /mnt > Where is `/etc` restricted (via whitelisting) in kodi.profile? answer: nowhere This is a bit unintuitive to me, as I always thought whitelists were for unlocking :) I don't know firejail profile configuration well, I reported this bug because this behavior in my opinion is dangerous: allowing kodi to access everything as well as delete files. Because of the support for plugins that don't necessarily pass any security audits and can even be potentially malicious (I know of one such case). I know that in the past firejail with the default kodi profile didn't allow this, so if it does now I consider it a bug, but if this behavior is expected then somehow I will understand it and close the bug :)

gitea-mirror commented

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

Author

Owner

@rusty-snake commented on GitHub (Jun 7, 2022):

I don't know how disable-mnt works, but from what I found it should only block access to /mnt

Yes, disable-mnt is about /mnt (and /media, /run/media, /run/mnt).

@rusty-snake commented on GitHub (Jun 7, 2022): > I don't know how disable-mnt works, but from what I found it should only block access to /mnt Yes, `disable-mnt` is about /mnt (and /media, /run/media, /run/mnt).

gitea-mirror commented

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

Author

Owner

@rusty-snake commented on GitHub (Jun 7, 2022):

This is a bit unintuitive to me, as I always thought whitelists were for unlocking :)

blacklist/whitelist (or denylist/blocklist/allowlist) describe the concept:

blacklist: Everything that has not explicitly forbidden is allowed.
whitelist: Everything that has not explicitly allowed is forbidden.

@rusty-snake commented on GitHub (Jun 7, 2022): > This is a bit unintuitive to me, as I always thought whitelists were for unlocking :) blacklist/whitelist (or denylist/blocklist/allowlist) describe the concept: - blacklist: Everything that has not explicitly forbidden is allowed. - whitelist: Everything that has not explicitly allowed is forbidden.

gitea-mirror commented

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

Author

Owner

@rusty-snake commented on GitHub (Jun 7, 2022):

I don't know firejail profile configuration well, I reported this bug because this behavior in my opinion is dangerous: allowing kodi to access everything as well as delete files. Because of the support for plugins that don't necessarily pass any security audits and can even be potentially malicious (I know of one such case).

You're right that the kodi.profile is rather weak and we could/should harden it (for the reason you said and the general idea). However to much hardening will break plugins and custom locations for media files so people will come here and say that kodi.profile is to strict and breaks kodi. That's the general problem with distributed sandbox configurations, find the compromise between security (strict as possible) and usability (weak as necessary). I'm not sure if kodi.profile should be whitelisting by default but we should at least add a comment ("Add the following lines to your kodi.local for whitelisting").

I know that in the past firejail with the default kodi profile didn't allow this

I do not see any such commits. Maybe you did this in your kodi.local?

@rusty-snake commented on GitHub (Jun 7, 2022): > I don't know firejail profile configuration well, I reported this bug because this behavior in my opinion is dangerous: allowing kodi to access everything as well as delete files. Because of the support for plugins that don't necessarily pass any security audits and can even be potentially malicious (I know of one such case). You're right that the kodi.profile is rather weak and we could/should harden it (for the reason you said and the general idea). However to much hardening will break plugins and custom locations for media files so people will come here and say that kodi.profile is to strict and breaks kodi. That's the general problem with distributed sandbox configurations, find the compromise between security (strict as possible) and usability (weak as necessary). I'm not sure if kodi.profile should be whitelisting by default but we should at least add a comment ("Add the following lines to your kodi.local for whitelisting"). > I know that in the past firejail with the default kodi profile didn't allow this I do not see any such commits. Maybe you did this in your kodi.local?

gitea-mirror commented

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

Author

Owner

@tomasz-c commented on GitHub (Jun 11, 2022):

You're right that the kodi.profile is rather weak and we could/should harden it (for the reason you said and the general idea). However to much hardening will break plugins and custom locations for media files so people will come here and say that kodi.profile is to strict and breaks kodi. That's the general problem with distributed sandbox configurations, find the compromise between security (strict as possible) and usability (weak as necessary). I'm not sure if kodi.profile should be whitelisting by default but we should at least add a comment ("Add the following lines to your kodi.local for whitelisting").

Hardening, even too much I think is a better solution than giving the appearance of protection. I would be more worried about the reactions of people who have had their data deleted :) I was convinced that the Kodi profile protects me as before and only by accident I noticed that it allows ... much.

I do not see any such commits. Maybe you did this in your kodi.local?

Unfortunately I don't have any individual configuration, but wouldn't it be possible to restore the behavior that used to be? That kodi had access only to default media directories?

If I may ask, can you suggest what in the kodi profile causes that:

noblacklist ${HOME}/.kodi
noblacklist ${MUSIC}
noblacklist ${PICTURES}
noblacklist ${VIDEOS}

it doesn't restrict access only to those directories?

@tomasz-c commented on GitHub (Jun 11, 2022): > You're right that the kodi.profile is rather weak and we could/should harden it (for the reason you said and the general idea). However to much hardening will break plugins and custom locations for media files so people will come here and say that kodi.profile is to strict and breaks kodi. That's the general problem with distributed sandbox configurations, find the compromise between security (strict as possible) and usability (weak as necessary). I'm not sure if kodi.profile should be whitelisting by default but we should at least add a comment ("Add the following lines to your kodi.local for whitelisting"). Hardening, even too much I think is a better solution than giving the appearance of protection. I would be more worried about the reactions of people who have had their data deleted :) I was convinced that the Kodi profile protects me as before and only by accident I noticed that it allows ... much. > I do not see any such commits. Maybe you did this in your kodi.local? Unfortunately I don't have any individual configuration, but wouldn't it be possible to restore the behavior that used to be? That kodi had access only to default media directories? If I may ask, can you suggest what in the kodi profile causes that: ``` noblacklist ${HOME}/.kodi noblacklist ${MUSIC} noblacklist ${PICTURES} noblacklist ${VIDEOS} ``` it doesn't restrict access only to those directories?

gitea-mirror commented

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

Author

Owner

@rusty-snake commented on GitHub (Jun 11, 2022):

Talking about access to files in $HOME, you need this:

mkdir ${HOME}/.kodi
whitelist ${HOME}/.kodi
whitelist ${MUSIC}
whitelist ${PICTURES}
whitelist ${VIDEOS}
include whitelist-common.inc

But there's much more space for improvements in kodi.profile

@rusty-snake commented on GitHub (Jun 11, 2022): Talking about access to files in $HOME, you need this: ``` mkdir ${HOME}/.kodi whitelist ${HOME}/.kodi whitelist ${MUSIC} whitelist ${PICTURES} whitelist ${VIDEOS} include whitelist-common.inc ``` But there's much more space for improvements in kodi.profile

gitea-mirror commented

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

Author

Owner

@kmk3 commented on GitHub (Jun 14, 2022):

@tomasz-c commented on Jun 11:

You're right that the kodi.profile is rather weak and we could/should
harden it (for the reason you said and the general idea). However to much
hardening will break plugins and custom locations for media files so people
will come here and say that kodi.profile is to strict and breaks kodi.
That's the general problem with distributed sandbox configurations, find
the compromise between security (strict as possible) and usability (weak as
necessary). I'm not sure if kodi.profile should be whitelisting by default
but we should at least add a comment ("Add the following lines to your
kodi.local for whitelisting").

Hardening, even too much I think is a better solution than giving the
appearance of protection. I would be more worried about the reactions of
people who have had their data deleted :) I was convinced that the Kodi
profile protects me as before and only by accident I noticed that it allows
... much.

Related: #4760.

@kmk3 commented on GitHub (Jun 14, 2022): @tomasz-c commented [on Jun 11](https://github.com/netblue30/firejail/issues/5179#issuecomment-1152981420): > > You're right that the kodi.profile is rather weak and we could/should > > harden it (for the reason you said and the general idea). However to much > > hardening will break plugins and custom locations for media files so people > > will come here and say that kodi.profile is to strict and breaks kodi. > > That's the general problem with distributed sandbox configurations, find > > the compromise between security (strict as possible) and usability (weak as > > necessary). I'm not sure if kodi.profile should be whitelisting by default > > but we should at least add a comment ("Add the following lines to your > > kodi.local for whitelisting"). > > Hardening, even too much I think is a better solution than giving the > appearance of protection. I would be more worried about the reactions of > people who have had their data deleted :) I was convinced that the Kodi > profile protects me as before and only by accident I noticed that it allows > ... much. Related: #4760.

gitea-mirror commented

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

Author

Owner

@kmk3 commented on GitHub (Aug 24, 2024):

The reported issue seems to be that kodi can access paths in the user home
other than its own paths and ~/Music, ~/Picures and ~/Videos.

In which case it seems to be intentional in order to avoid being too
restrictive and potentially breaking plugins and different user setups.

So closing as wontfix.

If this is not accurate, feel free to comment.

If you have a specific bug or improvement, feel free to open a new issue.

@kmk3 commented on GitHub (Aug 24, 2024): The reported issue seems to be that kodi can access paths in the user home other than its own paths and ~/Music, ~/Picures and ~/Videos. In which case it seems to be intentional in order to avoid being too restrictive and potentially breaking plugins and different user setups. So closing as wontfix. If this is not accurate, feel free to comment. If you have a specific bug or improvement, feel free to open a new issue.

gitea-mirror referenced this issue

2026-05-05 10:22:44 -06:00

[PR #2904] [MERGED] Place quiet option cfr. all other profiles #4577

Rows
Columns

[GH-ISSUE #5179] kodi: can access non-media paths #2904

Description

Steps to Reproduce

Expected behavior

Actual behavior

Behavior without a profile

Environment