Auto-connect request for OpenSearch snap

Hello,

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:

- log-observe
- mount-observe
- process-control
- procsys-read   # custom plug
- system-observe

The procsys_read plug reads from the system-files interface, and is described here.

The snap can be found here.

Thank you

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)

well, the system-files interface could as well just be a one liner like: /sys/fs/cgroup/system.slice/snap.opensearch.daemon.service/

and the other bits added to the respective interfaces …

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

So if I understand these are the read accesses:

      - /proc/cgroups
      - /proc/self/coredump_filter
      - /proc/sys/vm/max_map_count
      - /proc/sys/vm/swappiness
      - /proc/sys/net/ipv4/tcp_retries2
      - /sys/fs/cgroup/system.slice/snap.opensearch.daemon.service/*

/proc/self/coredump_filter is taken care by process-control once the PR land.

/proc/sys/net/ipv4/tcp_retries2 should be accessible with network-observe afaict?

proc/sys/vm/max_map_countis available under system-observe already

/proc/sys/vm/swappiness is not available anywhere but could be added to system-observe I think

We are left with:

/sys/fs/cgroup/system.slice/snap.opensearch.daemon.service/ that if it was the last thing needing access could be a system-files

/proc/cgroups could be added to system-observe?

@alexmurray what are your thoughts on these?

1 Like

Thanks for the analysis @pedronis - yep that sounds good to me.

1 Like

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?

yes, reduced to one entry though. Until we find more use cases like this, this seems a reasonable approach.