@arubislander said in Need help for application building:
Is the clickable application started in some kind of container / systemd-cgroup or it is just started with reduced privileges (given by apparmor settings?).
The resulting click package (which could also be assembled in other ways, but clickable is the easiest) that can be installed on a device running UT does not run in a container, but is indeed constrained by apparmor policies.
I was wondering if there is some kind of overlayfs thing. I did expected to have application installed into standard paths (i.e. application can by started from PATH). It seems the content of package is simply extracted into /opt/click.ubuntu.com/app-name/version and LD_LIBRARY_PATH and relative paths are used.
BTW the container approach sounds like a doable workaround how to run 16.04 apps in 20.04 ubuntu. For some reason, I was thinking that this kind of container is used for normal run of apps.
I am wondering what is the best way to debug apparmor setting.
Have you seen this page? It details most the apparmor policy groups that are currently available to app developers.
Yes, I have seen that page, but I am wondering how is it done technically. Those methods looks orthogonal to each others.
- Some of APIs groups looks like dbus interface (for example contacts),
- others looks like work with block device (for example camera reads /dev/video0 -> gstreamer -> qt -> app).
- For example for video_files_read I would expect some QDir dir("Pictures/MyPictures").entryList(...);
My application is using some Blootooth Low Energy library. I am wondering if it goes via standard bluetooth api or it is bypassed. I will probably find the answer immediately after first run, but I am waiting for hardware delivery so I am stating unnecessary questions ;-D
I guess, I will set "unconfined" mode and will try to find some kind of audit log which should report which permission was used.
I tend to think it works better the other way around. Once you have developed your app, remove "unconfined" mode and use the above list to add the policy groups you obviously need. Then keep an eye on the logs, as AppArmor
will complain if you are missing any permissions.
It would be great to know which log exactly to watch. This is one bit I haven't found in docs.
Next it would be great to have a link to source code where the apparmor policy are defined.
I am trying to summarize knowledge about ubports for myself into blog post. WIP version is at https://board.net/p/ubports-en
Looking forward to seeing this expand. You might also be interested in helping update the official documentation
Right, but first things first. The document was google translated text I had. I need to clear facts first, then polishing my grammar and then I can consider contribution to documentation. I definitely want to publish it in my blog and I am not against republishing it anywhere else (e.g. ubports blog)