Classic confinement request for hotsos snap

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 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?


@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 - 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 -

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.

@dosaboy ping, can you please provide the requested information?

Hi, finally got around to testing this some more. I added a bunch more interfaces and the stage deps mentioned and now i am down to:

$ snap connections hotsos
Interface Plug Slot Notes
home hotsos:home :home -
log-observe hotsos:log-observe :log-observe manual
mount-observe hotsos:mount-observe :mount-observe manual
network-observe hotsos:network-observe - -
openvswitch hotsos:openvswitch :openvswitch manual
removable-media hotsos:removable-media :removable-media manual
system-backup hotsos:system-backup :system-backup manual
system-observe hotsos:system-observe :system-observe manual
$ hotsos 2>&1| egrep “Permission|subprocess.CalledProcessError|permitted”
|Cannot open netlink socket: Operation not permitted
subprocess.CalledProcessError: Command ‘[‘ip’, ‘-d’, ‘address’]’ returned non-zero exit status 1.
PermissionError: [Errno 13] Permission denied: ‘/proc/buddyinfo’

It’s a pretty long list of connections to have to add each time someone installs the snap, is there a way to have them automatically connected? I’m not sure why i’m still getting an EPERM from ip and that proc entry.

you likely also need the network-bind plug …

and you can indeed turn this request for classic confinement into a request for auto-connecting these interfaces, just change the topic to reflect this …

1 Like

@dosaboy - hello, is the suggestion above good for you?

It fixed the ip issue but there are still others e.g.

INFO: analysing localhost since no sosreport path provided
ls: cannot open directory ‘/sys/block/’: Permission denied
Traceback (most recent call last):
File “/snap/hotsos/x1/plugins/storage/parts/”, line 5, in
File “/snap/hotsos/x1/common/”, line 154, in call
File “/snap/hotsos/x1/plugins/storage/parts/pyparts/”, line 39, in call
File “/snap/hotsos/x1/plugins/storage/parts/pyparts/”, line 20, in get_device_info
for line in cli_helpers.get_ls_lanR_sys_block():
File “/snap/hotsos/x1/common/”, line 29, in catch_exceptions_inner2
return f(*args, **kwargs)
File “/snap/hotsos/x1/common/”, line 309, in get_ls_lanR_sys_block
output = subprocess.check_output([‘ls’, ‘-lanR’, ‘/sys/block/’])
File “/usr/lib/python3.6/”, line 356, in check_output
File “/usr/lib/python3.6/”, line 438, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command ‘[‘ls’, ‘-lanR’, ‘/sys/block/’]’ returned non-zero exit status 2.
-Traceback (most recent call last):
File “/snap/hotsos/x1/plugins/kernel/parts/”, line 5, in
File “/snap/hotsos/x1/common/”, line 154, in call
File “/snap/hotsos/x1/plugins/kernel/parts/pyparts/”, line 139, in call
File “/snap/hotsos/x1/plugins/kernel/parts/pyparts/”, line 113, in get_memory_info
File “/snap/hotsos/x1/plugins/kernel/parts/pyparts/”, line 93, in check_nodes_memory
nodes = self.numa_nodes
File “/snap/hotsos/x1/plugins/kernel/”, line 129, in numa_nodes
for line in open(BUDDY_INFO):
PermissionError: [Errno 13] Permission denied: ‘/proc/buddyinfo’

I am also still uncomfortable with the fact that if we run in confined mode we run the risk of false negatives which would render the tool unreliable so would prefer to pursue supporting classic mode. If that is simply not possible then ill just have to build a debian package instead which would be a shame.

as @emitorino suggested before, you should really use snappy-debug from the snappy-debug snap and run it in parallel to your app, there are interfaces for accessing block devices as well as for checking memory and the tool should suggest the correct interfaces to use … if there are still missing bits we might need to extend an existing interface or add a new one …

@dosaboy, there is a process and criteria to grant classic confinement to snaps. Your request is not directly falling under the supported categories so we are trying to help you snap your app while keeping under strict confinement (because of the reasons already explained in the previous comments).

Can you already confirm the snap is providing false positives after fixing the denials?

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

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

@dosaboy: 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.

Hi, sorry for the delayed response. In response to the previous question this is a debugging tool that, when run against an host, is ordinarily run as root (similar to the sosreport tool) and as a result assumes that it has access to everything on that host. So while i can add interfaces to provide access as and when i become aware that it is needed I think that runs the risk of the tool being run and not having access to something I am not yet aware of and therefore providing inaccurate results. I hope that answers your question.

1 Like