Docker stack ignores cap_add and privileged option within compose file

Docker Hub Issue Tracking
#1

Hi,

I tried to build a nfs-Ganesha container service/stack, to automate the redeployment of the container during a server failure. I was able to build the nfs-Ganesha server from scratch and deploy the container with the required functionality together with a macvlan.

I just started the container with:

docker run -it --rm --name=nfs-ganesha-server1
–privileged --network $NET_NAME
-e GANESHA_LOGFILE=${GANESHA_LOGFILE}
-e GANESHA_CONFIGFILE=${GANESHA_CONFIGFILE}
-e GANESHA_OPTIONS=${GANESHA_OPTIONS}
-v /sys/fs/cgroup:/sys/fs/cgroup:ro
-v ${V_EXPORT}:/export
-v ${V_GANESHA_LOG}:/ganesha_log
-v ${V_GANESHA_CONFIG}:/ganesha_config
-v ${V_TOOLS}:/tools
centos7_ganesha_v2.5-stable

So nothing special at this point besides the --privileged flag. I know, that the --privileged flag is a security problem, therefore I also tested the cap_add flag, and have seen, that cap_add=SYS_ADMIN also do the work for me.

Since I require an automated redeployment to another server, I generated a Docker Swarm and tried to build a service. I recognized, that docker stack doesn’t support the privileged or cap_add flag. So I searched for another possiblity and found within the Docker compose documentation, that both options are supported with V3


So I wrote the following compose file

version: "3"
services:
ganesha_base:
image: centos7_ganesha_v2.5-stable:latest
networks:

  • swarm-macvlan
    volumes:
  • /sys/fs/cgroup:/sys/fs/cgroup:ro
  • /some_path/nfs-ganesha/persistent_export:/export
  • /some_path/nfs-ganesha/log:/ganesha_log
  • /some_path/nfs-ganesha/ganesha_config:/ganesha_config
  • /some_path/nfs-ganesha/container:/tools
    deploy:
    replicas: 1
    update_config:
    parallelism: 1
    delay: 60s
    failure_action: rollback
    monitor: 60s
    restart_policy:
    condition: on-failure
    delay: 5s
    max_attempts: 10
    window: 120s
    env_file:
  • ./ganesha.env

privileged: true #This option is just ignored!

cap_add: #This option is also just ignored

  • ALL
    restart: on-failure

#########################################
#NETWORK is created through an extra step
#########################################
networks:
swarm-macvlan:
external: true

The stack was generated, and I was also able to log into the deployed container. But then I realised, that I recieved the same error, as when I start the container through docker run without the cap_add or privileged flag. It seems for me therefore, that this options are silently dropped without any notice…

After some extrended google search I found this remark, that both options are not supported within the Compose file format 3, what is required for docker stack…

https://www.w3cschool.cn/doc_docker_1_13/docker_1_13-compose-compose-file-index.html

So I don’t know, if this is a bug or a error within the documentation. Since this is really important for my project, it would be great to get some clarification, if it is a bug or not. It would be also interesting to know, if there is a solution possible to deploy services with extended capabilities to a docker swarm.

Some informations to the used system:

Swarm of 3 servers with the following settings:
Client:
Version: 17.06.2-ce
API version: 1.30
Go version: go1.8.3
Git commit: cec0b72
Built: Tue Sep 5 17:16:07 2017
OS/Arch: linux/amd64

Server:
Version: 17.06.2-ce
API version: 1.30 (minimum version 1.12)
Go version: go1.8.3
Git commit: cec0b72
Built: Tue Sep 5 17:16:07 2017
OS/Arch: linux/amd64
Experimental: false

Best regards,

Stephan

#2

Ok, we can ignore, the cap_add option. There is a remark, that I have missed, that this flag is not supported with V3 and swarm in the documentation.

Nevertheless, the privileged flag does not work and there is also no such remark.

#3

Is there nobody that can say anything to my problem?