I am working on a Snap for OpenSearch, and the latter makes heavy use of the local filesystem, in addition to reading kernel values, making use of coredump_filter etc…
I would therefore like to request the auto-connect permissions for the following:
Wow that procsys-read interface seems huge… in the past we have created custom interfaces like greengrass-support and docker-support for snaps which require these sorts of more privileged accesses - however I guess now with system-files perhaps we have a better solution - @pedronis could you comment on whether you think a new opensearch-support interface would be a better solution here compared to using system-files for these accesses? Whilst this may work I wonder that it violates the spirit / intention of system-files.
no, that’s definitely too much for system-files, it’s very brittle to review at that level. I think we need to consider an opensearch-support interface or see if there’s a pattern there? it seems it’s trying to read its own cgroup hierarchy?
a couple of /proc things there are already covered by system-observe or could be added there (swappiness)
So what would be the way to proceed from here? Do I need to create a new interface or do we proceed as is given it’s only a read access to its own cgroup?
ps: here is the version I’m trying to upload to the store
Thank you for the details @pedronis!
You’re right, /proc/sys/net/ipv4/tcp_retries2 is part of network-observe.
I made a PR to include /proc/sys/vm/swappiness and /proc/cgroups in system-observe.
Do I understand correctly that /sys/fs/cgroup/system.slice/snap.opensearch.daemon.service/ currently stays as is?
Could you please update your snap with the alternatives suggested? The latest I see still contains the procsys-read iface reference with huge list of system-files entries.
I see the PR to extend system-observe was merged, so we should be good there. Meanwhile, I am +1 for auto-connect log-observe, mount-observe and system-observe ifaces since all seem required for searching purposes on the system.
Also, whats the reason to auto-connect process-control?
I proceeded with the changes, they can be found here.
@emitorino the reason behind the process-control use is the fact OpenSearch needs to read/write in the /proc/self_pid/coredump_filter directory (here is the PR where I patched it on snapd for the said use)
Could I also get the approval for the 2 remaining ones?
process-control
cgroup-service-read (previously named procsys-read - but now with a much smaller scope)
+2 votes for, 0 votes against, granting auto-connection of log-observe and system-observe. This is now live. (mount-observe was already granted for revision # 1)
@medib thanks for sharing the explanation about the need for auto-connecting process-control and pointing to the PR. But since process-control allows system-wide process management and this is not an expected opensearch functionality, I would prefer the user has a voice on granting such broad access so I am -1 for auto-connecting process-control to this snap. Can other @reviewers please vote?
I am +1 for auto-connect system-files with read access to /sys/fs/cgroup/system.slice/snap.opensearch.daemon.service. If possible, could you please rename the iface reference to be sys-fs-cgroup instead of just cgroup so the access being granted is clearer? Can other @reviewers please vote?
+1 from me for use of and auto-connect of system-files named sys-fs-cgroup-service (can you please drop the redundant read part of the name?) for read access to /sys/fs/cgroup/system.slice/snap.opensearch.daemon.service.
I also tend to agree on process-control being a bit too much authority for opensearch to be granted auto-connect for this - does the snap still function if this is not connected?
If the snap can function without process-control (but in say a degraded state) then I think it is fine for it to remain as manually connected. However, if the snap is not even able to say start up without this being connected then it would be more appropriate for auto-connect - can you clarify?
I tested multiple scenarios and it seems that the accurate representation is “the snap can function without process-control (but in say a degraded state)”, the degraded state would be with regards to ulimit -l unlimited and coredump_filter - but opensearch is able to run and be used.
I think we’re fine for now, if in the future we come across a use case where it turns out to be crucial, I’ll let you know.
Thank you Alex and everyone for all the support, it was very helpful!
Ok let’s leave process-control to remain as manually connected for now.
+2 votes for, 0 votes against auto-connect of system-files named sys-fs-cgroup-service or read access to /sys/fs/cgroup/system.slice/snap.opensearch.daemon.service. This is now live.