[sos-devel] sosreport and snap (sandboxing) issue

Bryn M. Reeves bmr at redhat.com
Fri Oct 19 14:26:31 UTC 2018


On Fri, Oct 19, 2018 at 03:19:50PM +0800, Pierre Equoy wrote:
> Hello!
> 
> I've been trying to package sosreport as a snap [1] along a small tool I've
> developed to submit issues in a bugtracker.
> 
> I've been facing an issue with several plugins (e.g. the pci or usb ones)
> which generate empty log files. After some investigation [2], I discovered
> that the culprit might be sosreport itself given that it hardcodes paths in
> the $PATH environment variable [3].
> 
> For instance, I found that replacing
> 
>     PATH = "/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games" \
> + ":/usr/local/sbin:/usr/local/bin"

The value of PATH is policy controlled (as you found). This is so that
distributions that have moved things around can set the appropriate
path set based on version or other information (e.g. Red Hat made the
"UsrMove" switch a few years ago). It (and the --sysroot support) are
also used in some cases where sos runs in a container (Atomic Host).

That said, I would have thought that you typically want to run the
commands that are present in the host's regular bin/ paths, rather
than from snap.

I'm not that familiar with snap's runtime model and whether or not it
uses any kind of container or other literal sandboxing. If that is
the case then you may want to look at how the Atomic policy works and
the use of "super-privileged" containers (that map in parts of the
host file system to the container namespace where sos runs).

Otherwise, if it's just a matter of using different paths then you
just need to create a new e.g. UbuntuSnapPolicy that subclasses the
UbuntuPolicy and set up the correct paths there.

For now you will need to modify sos locally to support this, but if
a new policy and other changes are submitted upstream they should be
included in the next sos release.

Regards,
Bryn.




More information about the sos-devel mailing list