Sailjail does not apply when starting from CLI

REPRODUCIBILITY: Yes
OS VERSION: 4.6.0.13
HARDWARE: Xperia 10II
UI LANGUAGE: -
REGRESSION: Don’t know

DESCRIPTION:

I came across this quite by accident while working on a simple new app, when starting it directly from CLI with sailfish-qml appname audio worked whereas when starting from the Application menu it did not because I had not set sailjail permissions.

It could be that this behaviour is on purpose but it is still quite surprising to me.

PRECONDITIONS:

.desktop file with empty permissions list and app that uses things that require permissions.

STEPS TO REPRODUCE:

I think the description speaks for itself

EXPECTED RESULT:

I would think that sailjail would be applied irrespective to the way an application is started.

ACTUAL RESULT:

It seems that it is only applied when the application is started through it’s .desktop file.

MODIFICATIONS:

ADDITIONAL INFORMATION:

Please note that while the commit also fixes the application name I tested it with an empty Permissions=

Absolutely by design.
Imagine all the binaries possibly being launched from CLI (be it by a user or something else) having to have a sailjail config. Quite impossible to do. (And if you need that, SELinux is probably better suited than FireJail, which is designed for “Desktop” applications.)

You can however apply SailJail from CLI by doing some thing like

sailjail -p <desktop file name> /usr/bin/sailfish-qml appname options
6 Likes

I totally hear you and understand the limitations but aren’t sailfish-qml apps by definition desktop apps?

SailJail applies before invocation of the application (or in your case shared launcher application) so that it applies the same to apps that own main() themselves.
Speaking as someone who has made a few qml-only apps - doing that, i.e. not having c++ code and ownership of main() is actually fairly rare. So implementing jailing at that point (sailfish-qml) would be inapplicable for the 80-90% of other apps.

1 Like