EACCESS_DENIED when following symlink in $HOME outside of $HOME

[almereyda]

After adding a graph following a symlink in the directory chooser dialogue, it is not possible to write to it.

An EACCESS error is thrown: Permission denied.

This is due to the sandboxing of the inherited file system link and the created portal file system within /run/user/1000/doc/by-app/com.logseq.Logseq/(.*) and within /run/user/1000/doc/\1.

After giving direct access to the inner symlink path and the outer real path of the desired directory with Flatseal, and using its absolute real path within the directory chooser, the graph could be written again.

[kanru]

Is the file outside of $HOME?

This is expected because the default sandbox only allows home access. It was chosen to balance ease of use and security.

If you need to access files outside of home then using flatseal to grant more permissions is the right way.

[almereyda]

Yes, the files live outside of home. The Flatseal way works, but I would encourage people to use the absolute path without Symlink, for I haven't tested the other case.

The display of the last path fragment of /run/user/100/doc/(.*) was unexpected in LogSeq.

Could LogSeq try to find out if it is running in FlatPak, and if so, if the chosen directory will be a portal to another? If so, one could try denying the addition attempt, and respond with an informative error message that instructs users to work around this limitation.

Else, what could we do to increase the system integration here? Will we resort back to the FlatPak default, and only claim paths in $HOME as valid sources for graphs? I'm open to any suggestions.

[kanru]

I haven't test portal for a while. Electron didn't support portal very well, electron/electron#31258 is one ticket that I knew of to improve the support, but it was closed due to inactivity.

If we can use portal then we don't need to have file path permission at all.

Let me find sometime to test portal + electron again.