Classic confinement request for hotsos snap

Hello snappers. We have a tool called hotos that we use to perform analysis of both sosreports and live hosts. It comprises of a set of “plugins” that extract application-specific information for applications such as Openstack, Kubernetes and Ceph and presents findings that might help in the debug/analysis of problems. The snap been strictly confined from the start and this works well for the scenario where you want to analyse a sosreport but less well when wanting run against an actual host. This is basically because, like the sosreport tool itself, it needs access to basically everything on the system in order to collect information relevant to the application that is running including network information, logs, etc configs, /proc info as well as locations specific to the application itself e.g. /var/lib, /run etc etc. Of course some of these locations can be accessed with the use of existing interfaces but some are not and I believe that in this instance requiring interface for all these areas will be counterproductive. As such I believe the appropriate way to allow users to run this on hosts is to allow classic mode. It is probably worth mentioning that the target audience is likely the same as those who already use tools like sosreport and as such expect them to be able access any data necessary. Currently to achieve this users have the install the snap and then run the script like /snap/hotsos/current/hotsos.sh which i would really like to avoid. I look forward to hearing your thoughts. Thanks.

  • Ed

[1] https://snapcraft.io/hotsos

Hi @review-team, would it be possible to get a response for this request? If there is any other information I can provide please let me know.

Hey @dosaboy, apologize for the delay.

Could you please describe the locations that you consider are not accessible with the use of interfaces? And also why you consider requiring such interfaces will be counterproductive?

Please remember classic snaps are not installable on Ubuntu Core devices and also run in the global mount namespace, which means great care must be taken for the snap to work reliably across distributions. Ideally we try snaps to keep under strict confinement, since classic effectively grants device ownership to the snap.

Thanks!

Thanks!

Hi @emitorino , thanks for taking the time to review my request. This application is used by support teams and operators to analyse and debug applications like Openstack and Kubernetes. Much like the tool sosreport it assumes it has unrestricted access to a host in order to be able to collect information and make decisions on the health of an application based on the state that it observes. Hotsos is read-only and does not modify the state of a host, it merely gathers information, presents it to the user and makes decisions about whether the host/application is affected by any known bugs or issues.

An example of what happens when I run the confined snap on a host is https://pastebin.ubuntu.com/p/Chwpt7D4qk/ i.e. can’t access locations such as /var/log/, /etc/, /var/lib/* and /proc/* and cannot observe ps which, combined with other information is how it detects which applications/binaries are running/not running on host.

I have used interfaces in my other snaps and both understand and appreciate their worth. They work well in scenarios where you have specific requirements and can allow access to those things and nothing else. This application is somewhat the opposite which is why i think it will be very hard to make it depend on interfaces for access while at the same time avoiding having false reports simply because something that it would otherwise be able to observe/access is now restricted due to insufficient privileges. If you have suggestions on interfaces or appoaches I should try I am more than happy to give them a go but as I state I beleive that in this case a restrictive approach will introduce risk to my application that could render it unrelialble and unsusable. Thanks. Ed.

1 Like

Hey @dosaboy,

  1. For /var/log/* you can plug log-observe
  2. For /var/lib/* and /etc/* you could plug system-backup
  3. For /proc/* you could plug system-observe

Could you please try those, and if you still experience denials run snappy-debug which will suggest other interfaces needed?

Thanks!

@dosaboy just wondering if you had a chance to try the suggestions from @emitorino above?

@dosaboy ping, can you provide the requested information?

@dosaboy - ping, this request cannot proceed without the requested information?

Hi sorry i’ve been very busy lately but ive finally found some time to try this out. It still won’t give me access to everything i need though e.g. ps, ip, /var/lib, df, /proc and so even with those interfaces you mention added and connected i still have some things i cannot access - https://pastebin.ubuntu.com/p/DsCzQJZdWs/. But my point is more that for example if i add some code that depends on the existence of some file under /var/lib/foo or ps entry and my code is set to skip the check if the entry does not exist yet it does exist but rather just cant access it, then that is a false negative and renders my checks somewhat untrustworthy. So yes i can keep adding more interfaces to ensure that more is accessible but I still have this risk that the tool will think something does not exist when actually it is just that it doesn’t have access. I look forward to hearing your thoughts on this.

And for completeness here is the snappy-debug output - https://pastebin.ubuntu.com/p/xkVYDSrf9y/

you should add util-linux (or just explicitly lscpu from util-linux) to your snaps stage-packages …

most of /proc/*/mount* errors should go away if you add and connect the mount-observe plug

access to the ip command can be achieved by adding and connecting the network-observe plug …

@dosaboy Can you please try the suggestions from @ogra above and let us know if you require any futher help.