Classic confinement for austin

I would like to request a classic confinement review of the Austin snap

Reason Austin targets Python applications. If run with strict confinement, Austin cannot be used to spawn applications as child processes because, in most cases, modules will be missing in the snap version of Python. Hence, access to the system Python installation is required.

Typically a snap would ship everything it needs rather than relying on the system to have it, in part since many systems won’t have everything so this isn’t usually a justification for classic confinement. Perhaps I’m missing something specific with your application-- can you describe what it does and how it is expected to work outside of snaps and how you see it working with snaps?

A user of Austin is somebody who is running a Python application. There is no assumption as to whether the Python application is a snap application or not. Typically, this would be a Python application that relies on the system packages. Suppose that said Python application is called foo. You would then run austin on it as, e,g.

$ austin foo

With this command, Austin forks itself and on the child process executes foo, which will likely spawn /usr/bin/env python(3). For the snap version of Austin, this would end up launching the Python interpreter included in the snap environment. Since the application was supposed to run with the system Python, it is quite likely that all the dependencies required by foo will be missing (not to mention any possible dependency on a specific version of the Python interpreter).

you should probably have mentioned that austin is a debugger/profiler for existing python apps, that would have made the judgement easier for jamie i guess :wink:

The requirements are understood, specifically that this application is a python debugger and therefore cannot predict what modules are needed by debugged applications or what the debugged application is meant to access.

In many ways this is akin to compiler snaps, but it is different. @pedronis and/or @niemeyer - thoughts on if this fits into the current thinking re classic?

My bad. I didn’t want to sell Austin as a profiler because, strictly speaking, it is not. It is just a frame stack sampler, whose main (or at least intended) use is to make profilers :slight_smile:

indeed, understood but a sentence like “this needs features like gdb” in the first post would have made everything clear from the start :wink:

seems the use case here needs to able to start an arbitrary other binary unconfined, is there any meaningful approach that would keep the invoking binary confined to some extent? or they would anyway boil down to be equivalent to classic?

It is technically possible to use a Ux apparmor rule (ie, where the caller is confined but it calls out to a binary that runs unconfined) but those are difficult to work with safely with templated policy like we have in snapd. This is especially true for an interpreted language. I suspect that the snap would need write access to things it is executing anyway which would be a trivial sandbox escape.

@jdstrand considering that, overall it seems a case were classic would be warranted, even more so than compilers, don’t know whether you agree?

I’m not usually involved reviewing in classic requests beyond gather requirements and processing them. That said, this for sure needs classic to function-- the question is whether or not the use case fits with the snappy design. I would argue that since we allow compilers in, it makes sense to let debuggers in too. I guess austin isn’t strictly a debugger, but it works a lot like one and can be used as one.

Yes, I think that line of reasoning is consistent. So I think this could go on with the usual process for classic.

The requirements for classic are understood.

@evan, @Wimpress, @popey, @Igor - can one of you perform the vetting for this request?

Vetting has been done, and I’m +1 on this for classic confinement.

Granting use of classic. This is now live.

Thanks for granting my request. Do I have to remove the first review ( which is blocking the newer one in order to get the snap built automatically?

I just responded via the store-- I re-ran the review but there is an issue you need to fix. Check your email for details.

Thanks. Revision 2 still has the “all” architecture setting. Revision 3 has “[ i386, amd64 ]”.

I believe this should fix the problem?

Looks like the build and the release went “fine”. However, I can only see a i386 build, which is no good on amd64. Is it possible to trigger both i386 and amd64 builds and have the corresponding binaries installed on the correct architectures?

In terms of the store and reviews, it did fix the problem. You can either have a snap that has everything for all the architectures you support, have the snap figure out what to use at runtime and provide a list like you did in snapcraft.yaml, or you do separate builds for each architecture. People tend to do the latter via a build service like I suggest creating a new forum topic if you have trouble with whatever you decide on.