Hi we have an open-source CLI for our product. we need access to the docker service as the CLI runs the fuzzing tests inside different docker images to be able reproduce crashes better.
Hi, please see my response to a similar request: Request for docker for alero-connector
In short, could you explain why your application needs docker specifically and cannot use the confinement and container primitives that snaps provide directly? I’m not familiar with fuzzit, so I don’t know what kinds of things it needs to do.
@ijohnson Thanks for your reply. So I’m not quite familiar with what is container primitives?
One feature of fuzzit is regression testing which is implemented by running “docker run -it fuzzitdev/builder /run.sh” which downloads some of the tests stored on fuzzit and reruns them in the original environment.
Is it possible to initial “docker run” without docker interface?
Thanks,
Yevgeny
What is the actual application that you are running with /run.sh in the docker image fuzzitdev/builder? Why can’t you just run that command inside a snap with something like the following for your snapcraft.yaml:
apps:
fuzzit-cli:
command: run.sh
As to what I meant by container primitives, I meant mainly isolation from the host file system (all non-classic snaps see their rootfs as the base snap, so a snap with a core base sees an Ubuntu 16.04 root filesystem, even when running on something like Fedora, etc.)
I’m running a fuzzer that the user built. you can see this in the source.
The user also can choose on which container to run the fuzzer. it can be ubuntu,debian or almost any other.
I’m new to snap but I don’t quite understand how the apps can replace this logic in the code. Does that mean that my fuzzit CLI will have snap specific logic? If yes I guess it be less relevant for fuzzit as it’s mainly a developer tool and the user can just wget essentially from github releases.
Sorry for the delayed response here:
In this case, if you were to repackage fuzzit to use snap confinement mechanisms, the only “fuzzer container base OS” (if that makes sense) that you choose for the snap could be run would be the base snap that you choose for your snap, Ubuntu 16.04 (base: core) or Ubuntu 18.04 (base: core18), etc.
Yes, if you wanted to be able to publish the snap without using docker. However I think your snap could be a strictly confined snap if it used the docker interface and had an allow-installation rule for using the docker interface. I’m not sure if folks would grant an auto-connection for your snap, but I think it’s somewhat reasonable for this application, since this application relies on users providing docker containers to run and your application essentially tests/fuzzes the docker containers.
@reviewers thoughts on granting at least an allow-installation constraint for the docker plug here?
I don’t see anything https://snapcraft.io/fuzzit (or anything that jumps out on the upstream pages) that says anything about docker. I realize that is a bit of an implementation detail, but if someone is expected to manually connect the docker interface, it would probably be a good idea to explain why (though, the snap itself could do this by using snapctl is-connected docker and explaining that it needs to be connected and why.
+1 for use of but not auto-connection of the docker interface.
@reviewers - can others vote on this?
+1 to allow-installation, but -1 to allow-auto-connection - from reading online materials it’s also not clear to me that docker functionality is essential for fuzzit, so best to leave it as a conscious connection decision for the user.
- Daniel
Same from me - +1 to allow the docker interface at install but -1 to auto-connect it.
3 votes for, 0 against for use of docker
0 votes for, 3 against for auto-connect of docker
Granting use of docker. This is now live.
Thanks everyone I’ll try this out.