Classic confinement request for sosreport (was sos-arif-ali)

Hi Team,

I am in the process of creating a snap for sos, which is a tool that collects multitude of data from a system, that then allows a support personnel to analyse logs, data and configuration, and potentially diagnose and understand the problems better for customers/clients.

This tool is used by Canonical and RedHat quite readily for this purpose.

As per the guidance from snapcraft, it is strongly recommended to strictly confine snaps, and I have been going though this in an iterative process (2 weeks) and have been solving all the different issues that snappy-debug is showing. My current WIP for a potential PR for the sos project is here, which will show you the snapcraft.yaml that I am working against.

Below is the link to my latest snappy-debug output that I am still working on, and still need to iteratively go through and resolve issues that it is reporting.

I am using sos-arif-ali as a temporary staging for the snap, so that I can get internal folks and some RedHat folks to test, so that we can iron out any issues. At one point, either myself or one of the Engineering folks in Canonical will be asking for sos name to be released, so that we can publish the sanp under that name.

Thanks in advance

any feedback on this? unless you can suggest another way to do this?

Hey @arif-ali, apologize for the delay.

Keeping under strict confinement is indeed the recommended way of snapping your application, unless the requirements needed for your app to operate follows under the supported categories to grant classic confinement.

I inspected your snapcraft and I see you are using system-files for several different purposes which might be able to be obtained by plugging other interfaces which are more appropriate and less privileged instead.

So can you explain in detail the specific locations from the system you need to collect data from and why?


Hi @emitorino, thanks for looking at this for me.

sos application is a tool that grabs various configuration files for inspection for support personnel, as well as logs and such. Hence, depending on the applications that are installed on the system, and based on the plugins, it will potentially collect .

In the scenario, I was testing, this was my laptop, and so far these are the system files it touches. Typically sos is run on user sites where OpenStack, Kubernetes, MAAS, Juju is run, and grab the relevant support data for support personnel to inspect. So, in essence it will collect data from applications that sos doesn’t own itself.

Here’s my latest commit, with more data, which has now the least amount of snappy-debug output

I hope that makes sense.

IMHO sos makes more sense as a classicly confined application, it is a “debug tool” from the supported categories. The list of things that sos needs to execute will probably only grow over time and we don’t support using system-files for reading things in /proc or /sys, see reasons why this snap is not permissible in the store:

  • system files where the snap is not the clear owner (eg, /dev, /proc, /sys, /usr, etc).


Thanks @ijohnson,

I will work my way in getting this working correctly with classic confinement, and re-submit.

The one issue with classic confinement is that having configuration files and such, which will need to be customised in the same way I am doing with layouts, what would be the best way to achieve that?

Well with classic confinement your snap can just write to the normal file locations like /etc/sos/foo.conf without any restriction the way a deb would, does that not work for your program?

@arif-ali are you planning to request classic confinement? If yes please update this topic title and make sure you read the process for reviewing classic confinement snaps.

Otherwise, take a look at some interfaces like: log-observe , hardware-observe, system-observe, network-control, mount-observe and system-backup which should help with your needs (could not be enough though).

@emitorino, yeah likely now, considering the comments I’ve had on this by i-johnson. I have an initial piece on this, just need to test, and then get this requested

The system-files or the files sos accesses are not owned by the application itself, but accesses files all around the filesystem. As more plugins are added more files are likely to be collected, so the snap would need to continuously change, depending on new plugins that are added to the application.

@ijohnson, I think the issue was that we wanted to create sos.conf in /etc/sos or have it access specifically for the snap, that is used differently to the default application. But, snaps don’t create files in /etc, but can access with classic confinement. However, in strict confinement, I was going to be able to do this via layouts using strict confinement. I may need to patch the code itself, to change that specifically for the snap, if we are not able to do that.

@arif-ali it sounds like you should just use something like /etc/sos/sos-snap.conf or something if you want it to be different. You could also just use /var/snap/sos/current/sos.conf which will be snap confinement.

Indeed you cannot use layouts with a classic snap because the setup of the mount namespace is not the same at all.

For some reason, I am not able to change the title of the topic to get a classic review done for sosreport. Should I create a new topic, referencing this one?

@arif-ali I have changed the title for you.

1 Like

@arif-ali I notice you have just uploaded a classic snap named just sos - do you want to change this current request to be for that snap instead of this one?

Hi @alexmurray, yes, I registered (took ownership) of the name sosreport last week. So, yes, the request is for that now.

Ok thanks for confirming - since this is a debugging tool, the requirements for classic confinement are understood. I have also vetted the publisher, so granting classic confinement for sosreport. This is now live.

Thanks for everyone’s input into this, it’s very much appreciated.

One final thing, can we get auto alias of sos and sos-collector to point to sosreport.sos and sosreport.sos-collector. Unless this needs to go into a new thread?

Yes can you please make a separate thread for the alias request? That will make it a bit easier to evaluate.