Added the ability to define custom docker args in the plugin
configuration files for things like bind mounting dirs from
the host to the scanner image.
When parsing the atomic scan json files, we can now handle
'Vulnerabilities' or 'Results' for keys.
Added a --debug switch to the base atomic command to allow for
more specifics when an unwanted exception is raised.
Fixed minor bug where if no image/container is provided, the
scanner would still execute.
As more scanners besides openscap become available, atomic
can now begin to leverage them. The new scan function has
been broken out into its on file (scan.py).
The scan command itself now defaults to openscap but can
also be switched to blackduck with --scanner.
Atomic now can use a configuration file which is stored
in /etc/atomic.conf. The location of the atomic conf
file can be overriden with the environment variable
'ATOMIC_CONF'. In the case of the scan function,
we need the scanner defined in the configuration file
as well as the fully qualified image name and the
scan arguments. Optionally, you can provide additional
custom docker arguments for the scanner as well
Using self.ping(), we now check to make sure the docker
daemon is running before executing any code to display
atomic top.
This fixes a followup bug reported in:
https://bugzilla.redhat.com/show_bug.cgi?id=1300187#c5
Prior to dropping shell=true, shell expansion on run/install/uninstall was
working, now we break in the case of a command like
LABEL INSTALL 'bash -c "echo foo foo foo"'
Adding shlex.split rather then standard split will break this command into
['bash', '-c', '"echo foo foo foo"']
Which will be executed correctly.
It's nicer for branding the command. The more correct thing would be
to add it to the rpm-ostree daemon and pass through there, but we have
more important problems to fix for the production code path. This is
just for local development, so the slightly dirty way is just fine.
We now use the fully qualified image name (if not provided)
when dealing with atomic info and verify. This is because
skopeo requires a fq image name to do remote inspection. As
an upside, it also makes atomic a little more user friendly
as well.
tests/integration/test_info.sh
Temporarly disabled a test due to an issue with skopeo
In python-docker-py-1.6, the error handling improved
significantly. When a docker object cannot be found,
say with client.inspect(), it now throws a specific
exception called NotFound instead of the old, generic
Docker error. We have now updated some of our functions
to use the specific error because it was 'covering' other
docker client failures such as API compatibilies.
Also added a new custom Error class to handle a common
error message we used repeatidly. The new class is
called 'DockerObjectNotFound' and will output a
consistent messages and takes the dockerobject as input.
This is most commonly used when we verify the users'
input for validity and is different that the docker
client NotFound error.
When an RPM diff was performed between two docker objects, we
previously only store the name, version, and epoch of the RPM for
comparision. It turns out versioning information is also done in
the release portion as well.
This addresses https://github.com/projectatomic/atomic/issues/315
Atomic top was broken when you passed it valid container names
or ids. This is now fixed plus added a simple check for validate
that the names or ids are correct.
This addresses https://github.com/projectatomic/atomic/issues/314
In the case where the docker daemon is not running, each
Atomic subcommand was returning a different error message. This
PR unifies the errors messages for each subcommand.
This work was done for Bugzilla #1300187
Added a test case to test for failure when an image has
multiple repotags and is asked to be verified by image
id. This should result in a failure.
Also, turned verify debug off.
In the case where an image was tagged more than once, atomic
verify would sometimes resolve the wrong fully qualified name
due to an ordering issue in one of the supporting functions.
All uses of docker.Client() (docker-py) now should be using
the DockerClient definition in client.py. Any changes to the
client instantiation or function can now be changed in a
singular location.
Also, the DockerClient function has a fallback from
docker.AutoVersionClient to docker.Client using a try and
except condition. This fixes an issue raised in:
https://github.com/projectatomic/atomic/issues/302
where atomic cannot be built due to imports when dockerd is not
running.
We stopped carrying a patch in docker that allows for a RESTFUL
probe of remote registries. This function is being replaced
by a new package called skopeo.
The remote_inspection def was removed from the Docker.Client
class extension in atomic.py and is replaced by a def called
util.skopeo which returns the same json-based results.
400 Client Error: Bad Request ("client is newer than server (client API version: 1.21, server API version: 1.20)")
AutoVersionClient is in docker-py since 1.1:
https://github.com/docker/docker-py/blob/master/docs/change_log.md#110
Logic around features available in docker engine since version X is very
well defined in docker-py: it won't allow you to use a feature if it's
not available in docker daemon, e.g.:
9b3b096709/docker/api/exec_api.py (L12)
This addresses one of the two issues raised by bugzilla
1248038 where atomic is using shell=True on its subprocess
calls which exposes a security concern.
Two new functions were added to accomplish this. The
first is a util.chk_call which is similar to util.subp
but it uses the python function check call instead of
Popen.
The second function is atomic.sub_env_strings. Previously,
there was env variable substitution occuring with cmd_env and
the subprocess call. That was one upside of the shell=True
usage. Now, prior to calling util.chk_call, we pass the
intended command to sub_env_strings and use cmd_env to
perform the variable substitution.
We will address part 2 of the security concerns, which
is the handling of LABELS as strings, in a different
PR.
I noticed at least one spacing issue on the latest el7 build in those
outputs. This patch reworks the layout of the strings so that it's
easier to read in the source code and to make sure that there are no
spacing issues.
Text is exactly the same, other than fixing spacing and changing "hosts
network" to "host's network".
The async API has several advantages, namely:
- it doesn't take over the dbus message queue of openscap-daemon,
other users can still query it and interact with it
- it allows better scheduling in the daemon itself, daemon will
limit the amount of concurrent work
- in the future it will be possible to cancel the work (CTRL+C),
the change in atomic already does everything necessary, this
only needs to be fixed in the daemon
In case the user has an older version of openscap-daemon we fallback to
the old synchronous API with huge timeout.
Laymen users who are told to run a image may not understand
the docker run switches that have security implications. We
now look for the following switches:
* --privileged
* --cap-add
* --security-opt label:disable
* --net=host
* --pid=host
* --ipc=host
and output an appropriate security message.
Also, moved def run() from Atomic/atomic.py to Atomic/run.py
to reduce the size and the number of definitions in
Atomic/atomic.py.
Images or containers can now have an associated
man-like help page to help users understand more
about the image. Typical information included
are things like a longer description, if the image
needs to be installed, security implications, steps
to upgrade, etc.
The default behavior is for atomic to display
a file called help.1 (in man format) located in
the / of the docker object. This default
can be overriden with the HELP LABEL. The
HELP LABEL needs to be a fully qualified
command to work correctly.
With CentOS and Debian, 'makes' were failing due to a
maybe-no-member pylint error. The error is a false
positive. Added #pylint: disable=maybe-no-member to hush
it.
Depending on if a container has an allocated tty, you can get
different results from docker top unless you pass the -e
argument. Adding the -e option will give correct results
regardless.
This is documented in https://bugzilla.redhat.com/show_bug.cgi?id=1293063.
In 374d344 "stop" was converted to only expect the argument provided
to be the name/id of a running container. This eliminated the usage
where a user wanted to execute the "STOP" label from a container image
rather than actually stopping a named container. This commit re-enables
the functionality to be able to run a stop label.
