Docker stack ignores cap_add and privileged option within compose file

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

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.

Is there nobody that can say anything to my problem?