System-files request for iotdb-snap

store-requests
1

Hi all, I am currently developing a snap for the Apache IoTDB timeseries Database (https://iotdb.apache.org/). The snap can be found here: https://dashboard.snapcraft.io/snaps/iotdb-snap/

In the startup procedure of the database we need to check some system properties from /etc/sysctl.conf to adjust the memory usage and threads optimally for the system.

My snap got rejected in manual review with the hint to add a request here. The code can be found here: https://github.com/JulianFeinauer/iotdb-snap

I am happy for any feedback! Julian

2

I am +1 for use of the system-files interface with read access to /etc/sysctl.conf to be used for optimization purposes but since the snap is not the clear owner of such configuration file, I am -1 fro auto-connection. Can other @reviewers please vote?

Also, @jfeinauer could you please adjust the interface reference name to be etc-sysctl-conf so it better represent the access granted?

Thanks!

3

Thanks @emitorino for you feedback. Is there another or “snappier” way to achieve the same (this is my first snap)?

And i will do your suggested changes tomorrow!

4

Same here, +1 for system-files and -1 for auto-connection.

5

Thanks both of you @emitorino and @pfsmorigo! I thought the system-files plug was not auto connecting ir is there a configuration that i would need to change? Or do you mean something different?

Thanks in advance! Julian

6

Is there another or “snappier” way to achieve the same (this is my first snap)?

So I notice there are a bunch of snap interfaces that do allow the use of the sysctl binary but they don’t actually then allow access to the /etc/sysctl.conf file - in this case they are designed to allow the use of sysctl to set a particular value, not to read the existing configuration. Perhaps it might make sense to add this to an existing interface but for now perhaps it is best just to do this via system-files for a least privilege approach.

One question - do you also require access to /etc/sysctl.d/ since this can also contain sysctl snippets?

7

Thanks for the clarification. I tried the snap as is and it worked… all the access necessary is the one stated in this file: https://github.com/apache/iotdb/blob/762cd4ddea991dbfc6e87dcb68ad7d4564fda52e/server/src/assembly/resources/conf/iotdb-env.sh

So as fallback (if the request does not pass) I could also add a custom iotdb-env.sh with fixed values for memory and threads (which may or may not cause issues on some machines).

Regarding your question: I did a test with the snap as is on my test system and it worked so I guess the current access is sufficient…

8

Hmm isn’t it more important to read the actual value which is configured in the kernel rather than what is in the sysctl.conf file? In that case you require access to /proc/sys/net/core/somaxconn (since the other sysctl invocations mentioned in that file seem to be for non-Linux systems). And this is provided via the default snapd AppArmor template: https://github.com/snapcore/snapd/blob/master/interfaces/apparmor/template.go#L201

So based on that script I don’t think you should actually need to access /etc/sysctl.conf at all. Can you please clarify? Or can you post any AppArmor DENIAL message which you see in dmesg when running your snap without this access? Thanks.

1 Like
9

@jfeinauer - ping, can you please provide the requested information?

10

Sorry yes, i think you are right (although my knowledge of these Linux mechanisms is very basic). So i guess I’ll try to rewrite the script to only access somaxconn and change the snap accordingly, right?

11

Yes if you could please give that a go and let us know how it works out, that would be great. Thanks.

12

@jfeinauer ping, could you make iotdb-snap work with the suggested alternative?

13

@jfeinauer - hello, are you good with the proposed solution?

14

@jfeinauer since we’ve not heard back from you, we are removing this request from our review queue. When you have more time to respond, simply do so here and we can add the request back to the queue. Thanks!