New profile: obsidian #6314
New profile: obsidian #6314
Conversation
There was a problem hiding this comment.
I tried to clean it up and make it a redirect to electron-common:
obsidian.profile
# Firejail profile for obsidian
# Description: Personal knowledge base and note-taking with Markdown files.
# This file is overwritten after every install/update
# Persistent local customizations
include obsidian.local
# Persistent global definitions
include globals.local
noblacklist ${DOCUMENTS}
noblacklist ${HOME}/.config/git
noblacklist ${HOME}/.config/obsidian
noblacklist ${HOME}/.gitconfig
include disable-common.inc
include disable-devel.inc
include disable-exec.inc
include disable-interpreters.inc
include disable-programs.inc
include disable-xdg.inc
whitelist ${DOCUMENTS}
whitelist ${HOME}/.config/git
whitelist ${HOME}/.config/obsidian
whitelist ${HOME}/.gitconfig
ipc-namespace
no3d
# from `firejail --build` (0.9.72)
#private-bin basename,bash,cat,cut,electron*,gawk,git,grep,obsidian,realpath,tr
#private-etc ati,ca-certificates,drirc,fonts,gitattributes,gitconfig,gnutls,gtk-3.0,hosts,libva.conf,nsswitch.conf,vulkan,xdg
# Redirect
include electron-common.profile
Does it work?
Though I'm not sure about whitelisting in ${HOME}.
Is there a default/recommended "vault" location?
Are they usually stored anywhere?
No. My firejail package doesn't have "electron-common.profile". But there is just "electron.profile".
No, storage is located where the user specifies, there can be several of them. With your advice: obsidian.profile
electron.profile
Do I understand correctly that including profile at the end will override some parameters (if any, except noblacklist)? |
|
I don't have a lot of time right now, but I will be testing this and studying the firejail documentation more. I will be looking into this anyway as I use obsidian every day. Right now I'm trying to find the minimum acceptable parameters to run, then I'll deal with the Obsidian features that aren't working at the moment. For example, there is a function to open sites inside obsidian, as well as drag-and-drop and the like, which doesn't work at the moment. |
Please test with firejail-git: (That is, install firejail-git from the AUR if on Arch or just building There has been a refactoring of electron profiles and this should help ensure
Alright, then these should also be removed:
Or else it will have the same effect. Any whitelisting in
Please update the PR directly with new changes to make reviews easier. (I only posted my version in the comments because I rewrote most of it)
Yes, including a profile is roughly equivalent to copying and pasting its |
|
I have a few quandaries that I haven't sorted out yet:
Also, I haven't been able to fix the bugs yet: As well as the emerging warnings: I removed the permissions that are required for Obsidian plugins, I think it should be set by the user separately, as plugins can do anything. |
In general there's no X11 versus Wayland separation in the naming of profiles. Only when upstream applications target Wayland specifically, like firefox-wayland for example, we need to ensure there's a specific firefox-wayland.profile (which redirects to firefox.profile). AFAICT Obsidian doesn't need this.
Only difference in this context is blacklisting ${RUNUSER}/wayland-* when Wayland is not supported by the application, or for CLI apps in general. Again, AFAICT Obsidian doesn't need anything special here.
These warnings are common on OS'es that follow the HFS (Hierarchical File System) layout. Can be safely ignored on such platforms.
This can get tricky. Some distributions enable unprivileged user namespaces by default these days on their kernels, others still keep that disabled. Did you test replacing |
|
One last point I would like to clarify. Obsidian can open external programs like Dolphin (kde) or a browser. Is it possible to allow it to do this or is such a scenario possible only if the programme is run in the same sandbox? |
We generally don't support sandboxed file managers inside other profiles. Doing so would dramatically weaken such profiles. You can add support for opening links with Firefox. Doing so will need a few changes though: add a comment like the below:
|
|
I decided to leave the default network as most users will prefer to leave network access. I started getting this message, can you tell me what it means? I sorted the records (I hope I understood correctly what you meant). I didn't add the @default group, as its contents seemed redundant to me. |
I tried doing this, but when I try to open the link, nothing happens, it says in the output: Perhaps Obsidian opens external links in some other way and a different setting is needed? UPD: I tried what is said here #6275, but nothing changed. |
The private-bin option can become somewhat of a rabbit-hole. Your profile doesn't include |
This is a very commonly seen warning. Abstract unix sockets (see The Note that these are not the regular unix sockets found in /tmp/.X11-unix/*. |
To disable abstract unix sockets, it should be enough to pass I don't think that needs any patching and it seems to have been supported for Details: |
True. Yet it depends though. Some widely used DMs like Anyway, apologies for the mixup and the potentially confusing side-stepping here. |
Indeed, the problem is usually with login managers not supporting it directly Otherwise it's trivial to make it work (such as adding it to .xserverrc).
All good. |
I've added a note to my to-do list about this. Might make a nice general Firejail wiki addition. |
Co-authored-by: Kelvin M. Klann <kmk3.code@protonmail.com>
Co-authored-by: Kelvin M. Klann <kmk3.code@protonmail.com>
Co-authored-by: Kelvin M. Klann <kmk3.code@protonmail.com>
Co-authored-by: Kelvin M. Klann <kmk3.code@protonmail.com>
|
Why did you remove whitelists and add git? |
It's explained in the suggestion:
The git paths aren't new; they were in the original commit: Why were they removed? Isn't git used for syncing? |
You explained how whitelist works, not the reason for removing those instructions. Do I understand correctly that with the current profile without whitelist, the program running in the profile will have access to more files? If the answer is yes, then why give obsidian more than it needs?
Only when using the obsidian plugin, plugins are installed by users, there is nothing like that by default. |
Yes.
Because there is no default location for vaults, so a user may place (and
I think it makes sense to support common plugins on profiles, especially when In this case, the git paths are already read-only (see disable-common.inc). |
But Obsidian is not a text editor in the sense you are talking about (kate and the like).
So, I think that a user who uses firejail has to specify the path to his storage himself, in one of the available ways.
So I think it's better to do the maximum restriction via whitelisting, and not even include the Correct me if I've got something wrong. |
And just like other text files and git repositories, this folder can be placed
Where is the storage located?
I'm only talking about the git plugin. Syncing documents seems like a rather common use case. What would be the drawback of allowing the git paths?
Then where would the vault be placed? Have you actually tried what you're suggesting? Try to use the profile with no |
Of course not. The user is supposed to add their own add-in over the profile or edit the .desktop file to add whitelist={path to storage (vault)}.
The location can be anything, including outside ${HOME}, depends on the user's preference. When obsidian is started, you are prompted to open or create a storage (vault). Think of Obsidian more as a note-taking programme (thinking by writing) or a reference system, rather than a programme for opening arbitrary text files and documents. Although if there is such a tradition, you can leave the permission at
Yes, I am using the old profile with whitelists and added the
If reasoned that way you are right, on the other hand the usefulness of a particular feature is subjective. I personally use this plugin to be able to roll back and compare changes. Obsidian has an official synchronisation feature, it is available after purchasing a subscription. Again, the main reason I brought up the topic of removing git access is because it is not a default feature. If the user doesn't use this plugin, Obsidian and all other plugins will get access to some git configs, I'm not sure what's in there, but probably some personal information (deanomising) like email and such. Isn't that weird? Perhaps I initially misunderstood the "isolation philosophy". What is the point of giving a potentially malicious program (in this case a suspicious plugin) access to many files in ${HOME} (albeit read-only), even with I thought the programme should only allow what it needs and no more, anything else is not standard usage scenarios that may not be "safe". |
|
So... what else is left to do? |
|
Thanks @konstantin1722 - give it a try and send a fix if you run into problems. |
electron-common.profile and blink-common.profile already apply whitelisting in the user home, so ensure that the allowed paths are available as well. Relates to #6314.
https://obsidian.md/