3

I'm trying to do an offline deployment of a docker image with RPM on CentOS. My spec file is pretty simple :

Source1: myimage.tar.gz
...
%install
cp %{SOURCE1} ...
...
%post
docker load -i myimage.tar.gz
docker-compose up -d
docker image prune -af

I compress my image using docker save and gzip. Then, on another machine, I just load the image with docker and use docker-compose to run my service.

When executing the commands "docker load" and "docker-compose up", I got that error:

sudo: unable to execute /bin/docker: Permission denied
sudo: unable to execute /bin/docker-compose: Permission denied
sudo: unable to execute /bin/docker: Permission denied

My user is part of the docker group, I checked if the RPM file was executed using root, it is...

If I run the RPM on my dev machine, it works, if I execute the commands in a script that is not part of the RPM, it works...

Any ideas ?

Thanks in advance.

  • I'm not sure if this is the best approach, but it should work. Remember that it is always `root` that will be running the scriptlets. Permission denied sounds like it's somehow NFS mounted or something strange (which you wouldn't do with `/bin`). Have you checked SELinux? It could be stopping you. – Aaron D. Marasco Aug 17 '20 at 22:00
  • @AaronD.Marasco SELinux is in fact stopping me from accessing the docker-cli and docker-compose. If I use "setenforce 0" it works in fact ! Is there a safest way to do that ? – Pierre Jacobs Aug 18 '20 at 06:15

2 Answers2

2

You're probably being blocked by SELinux. You can temporarily disable it to check with setenforce 0.

If that is the problem (it is; this is a comment turned into an answer), some possible solutions:

  • You might be able to use audit2allow to change the denials into new rules to import.
  • Maybe udica will help. I don't know enough about it to tell.
Aaron D. Marasco
  • 6,506
  • 3
  • 26
  • 39
-1

I tried the first solution and it worked ! grep rpm_script_t /var/log/audit/audit.log | audit2allow -m mypolicy > mypolicy.te

The problem came from the fact that the RPM scripts didn't have the access to the container_runtime_exec_t:file entrypoint that I suppose, allow it to run containers like docker.

Thanks a lot for the tip !