So it seems that the path can be configurable, so /dev/shm/snap.${SNAP_INSTANCE_NAME}/performanceanalyzer/ would work (I assume having an additional directory level below snap.${SNAP_INSTANCE_NAME} is ok?).
However, the plugin requires the said directory to be already created, and I canāt seem to be able to do it from the install hook (in --jailmode at least).
I think you might be able to use the private option with the shared-memory interface in that case (since you then get a private /dev/shm which you can do what you want with, but only within your snap, it cannot be shared with other snaps etc). https://snapcraft.io/docs/shared-memory-interface
> grep /dev/shm /var/lib/snapd/apparmor/profiles/snap.opensearch.daemon
# App-specific access to files and directories in /dev/shm. We allow file
# access in /dev/shm for shm_open() and files in subdirectories for open()
# Description: Allow access to everything in private /dev/shm
"/dev/shm/*" mrwlkix,
Ah apologies, I see now that I was confused about how snapd was preparing the AppArmor profile in this case - and so the profile does not contain all the permissions that I had thought it would.
However, what is there is correct for shared-memory with private: true - I wonder if perhaps snapd should be updated to use a more permissive rule for the Allow access to everything in private /dev/shm case, ie:
"/dev/shm/**" mrwlkix,
which would allow to create directories under this path (rather than just files) - it would be worth testing this by editing the profile by hand to make this change (ie. make the single asterisk in this rule a double asterisk) and then running apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.opensearch.daemon and then re-start the opensearch daemon and see if this is then allowed.
If so we could look at making an update to this interface in snapd to support this use-case.
@jamesh since you did the original work on the private shared memory interface I would be interested to get your thoughts on this proposed change. Thanks.
I donāt see any obvious security problems with allowing a snap with private shared-memory access to create and access subdirectories under /dev/shm.
The application use case seems a bit weird though, since /dev/shm is really only there to support the POSIX shared memory and semaphore APIs. If they want to store other temporary files, /tmp is the obvious choice. But if modifying the upstream is not on the cards, the AppArmor change seems reasonable.
Thank you! the double asterisks ** fixes it. I can make a PR - it seems straightfoward. (PR)
Now (after this test), It seems I will also need read access to /proc/p_id/task/task_id/schedstat, do you think it would make sense I patch the system-observe interface by adding @{PROC}/*/{,task/*/}schedstat r,?
I see this PR has been merged. Itās been one month since we last discussed and I see opensearch successfully published in the store, so whatās the status of this request?
Hi @emitorino - both PRs were merged - Iām waiting for the new version of snapd 2.60.1 to be released on stable, so those changes can be picked up.
Once thatās done, I can enable the performance analyzer on the OpenSearch snap (which currently doesnāt support the said plugin)
Please feel free to mark it as done - thanks
Thanks for the confirmation @medib. I am then removing this request from our review queue. Feel free to write here again if for some reasons you experience issues with the new snapd version.