So, today morning I posted the link to my previous blog entry, and today we got a reply from the sailors! Pekka Vuorela was very quick in helping out. It's great to see that, despite the workload they most likely have on a day-to-day basis, the Sailors are still ready to help out when community members reach out! Kudos!
It seems however that the SailJail will pose quite an interesting challenge. Not only does it hide other applications to be visible from a given sandboxed app, it also allows access merely to files. If you look into libcontentaction's Exec action code, you will notice that at some point it validates the presence of invoker exe file, a helper executable to (you guessed) help launch (or re-launch) programs. Given invoker is not available from the SailJail, this part is skipped. The alternative is a fallback to glib's desktop utilities, which apparently also fail. The question is, why? Well, let's find out! One way to go for this is to install a debug version of glib, perhaps alongside Quickbar, with more debug logs. But there's a fancier way to do it, with the help of a tool called strace. So after installing strace from devel-su, we can launch Quickbar, and then in a root-ified terminal, do:
strace -p `pgrep debota` -e trace=!ppoll,recvmsg,sendmsg
which will attach the strace to the Quickbar process. When we then proceed to attempt to launch, say, terminal, we will get:
newfstatat(AT_FDCWD, "/usr/bin/invoker", 0x7fcb73cb10, 0) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
newfstatat(AT_FDCWD, "/usr/bin/invoker", 0x7fcb73cb10, 0) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
faccessat(AT_FDCWD, "/usr/bin/fingerterm", X_OK) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
and as can be seen, in the last entry, /usr/bin/fingerterm is not available to the sandboxed environment either. And dumping the items available in the /usr/bin folder from Quickbar confirms there's nothing but the executable itself there:
[D] AppDispatcher::startCachedApp:74 - Listing items in /usr/bin
[D] AppDispatcher::startCachedApp:76 - /usr/bin "/usr/bin/harbour-debota"
[D] AppDispatcher::startCachedApp:78 - Listing items in /usr/bin -> DONE
So this is expected, kindof. The operating system itself is in constant development, and so far it has been "easy" to get things to run on it, without unnecessary patches (which I am personally very proud of). It's to be expected that, once the security gets tighter, there will be less things that can be done. Pekka suggested to drop the SailJail, but that would exclude Quickbar from the harbour, which is not really ideal in my opinion. One is to wonder how apps in the sandbox can open other files; as the same mechanism (dropping SailJail) cannot be applied to all applications - it would just simply be counter-productive. So, there must be some other way to launch apps. The main inter-process communication mechanism on SFOS is DBus. And in fact, lipstick, the main compositor on SFOS, has an endpoint to launch apps:
method void local.Lipstick.WindowModel.launchProcess(QString binaryName)
however, it requires privileged permissions for the client application in order to be used.
This can be seen as very "hostile", but in reality is very important. In fact, it keeps the control of what is to be done with the system to the user. A user can do whatever, as root; however, unless it's the user itself acting, nothing should really happen.
So we have seen today that SFOS is tightening the security. Which is a good thing, albeit it becomes an interesting conundrum for me :).
Well, not much that can be done about this at this point in time; so let's continue without SailJail for now!
Another "breaking" change I noticed; all android apps have relocated to the user's own applications folder (under $HOME/.local). This is not a problem per-se, as we can just consider the specific directory for it. However, as we know, SFOS has transitioned from the "user" username, to "defaultuser" at some point in time. So we need to make sure we consider both locations; by only looking at the relevant one. We can decide that based on the existence of the /home/user folder, simple kludge for now, we'll #fixitlater kthxbye (onte to self: dont be too angry about this when you fix it :-) ).
After adding this, Android apps re-appear! Nice!
However, it seems the naming search is not 100% accurate and leaves out most of the entries. Also, not all app's launches are correctly detected (for example the Messaging app).
