Full SFOS downgrade / SailJail access issues in JBoy [solved]

General
#21

It should only be necessary to perform one of these two operations, preferably creating a new .desktop file in /etc/sailjail/applications/, as @nephros suggested.

So ultimately it seems to only need a …

devel-su echo -e "[X-Sailjail]\nSandboxing=Disabled" > /etc/sailjail/applications/harbour-jboy.desktop # Is the apps’ desktop file name correct? I have no idea!

… to achieve <whatever>.

P.S.: In general, I trust @ade’s assessments; here, that busybox does cause an issue and the two different workarounds he provided for resolving this. But sure everybody may err, including him or me.

Hence @jimjamz, please double-check your assessment: “In the end, removing/replacing the busybox binaries was not required.”

#22

Correct. Either one of the two operations is sufficient, having tested both exclusively.

My personal preference would be to add the entry to the existing .desktop file in /usr/share/applications as it’s a cleaner approach.

However, I can also understand why instead creating a new file in /etc/sailjail/applications/ would be preferred, for readability purposes (the existence of a file in that directory implies that app has sailjail disabled.

That is the name of the file and the script look correct, but prefixing the command with devel-su does not invoke the root password to be entered, and will automatically respond with Permission denied. Neither does concatenating the commands with &&. Better to have the two as separate steps?

#23

No, /usr/share/ is a “system” directory admins should not interfere with: This is why often a directory under /etc/ exists, the content of which overrides the one in the corresponding “system” directory. This is far more elegant, specifically in the case of .desktop files, because an admin only needs to add the parts which are to be altered or added.

[…] prefixing the command with devel-su does not invoke the root password to be entered […].
Better to have the two as separate steps?

Yes.
I never understood why this is sometimes necessary.

1 Like
#24

@jimjamz, cool, your comment at OpenRepos is well written and comprehensive! Thank you very much.