René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Docker Swarm Service Container : Capability prefixed with CAP_ cannot be deserialized (InvalidFormatException)","articleBody":"Docker: version 20.10.18, build b40c2f6\r\ndocker-java:3.2.8\r\n\r\n**Description**\r\nWe have a service deployed to a Docker Swarm, using docker-compose to set the IPC_LOCK capability, as follows:\r\n\r\n```\r\nservices:\r\n  myService:\r\n    image: myImage\r\n    cap_add:\r\n      - IPC_LOCK\r\n```\r\n\r\nCalling the docker-java `InspectContainerCmdImpl` to inspect the container on the node to which the service task has been deployed fails and produces the following exception:\r\n\r\n```\r\n2022-10-11T14:40:41.800756150Z java.lang.RuntimeException: com.fasterxml.jackson.databind.exc.InvalidFormatException: Cannot deserialize value of type `com.github.dockerjava.api.model.Capability` from String \"CAP_IPC_LOCK\": value not one of declared Enum instance names: [ALL, SYS_BOOT, DAC_OVERRIDE, NET_RAW, BLOCK_SUSPEND, FOWNER, IPC_LOCK, IPC_OWNER, SYS_PACCT, NET_BIND_SERVICE, WAKE_ALARM, FSETID, DAC_READ_SEARCH, SYS_CHROOT, SYS_RAWIO, SYS_ADMIN, KILL, MAC_ADMIN, SYS_RESOURCE, CHOWN, SETPCAP, SYS_PTRACE, NET_ADMIN, SETFCAP, SYS_NICE, LINUX_IMMUTABLE, AUDIT_CONTROL, LEASE, AUDIT_WRITE, SYS_MODULE, MKNOD, SYSLOG, MAC_OVERRIDE, SYS_TIME, SETGID, SETUID, SYS_TTY_CONFIG, NET_BROADCAST]\r\n2022-10-11T14:40:41.800761129Z  at [Source: (com.github.dockerjava.core.DefaultInvocationBuilder$2); line: 1, column: 2062] (through reference chain: com.github.dockerjava.api.command.InspectContainerResponse[\"HostConfig\"]-\u003ecom.github.dockerjava.api.model.HostConfig[\"CapAdd\"]-\u003ejava.lang.Object[][0])\r\n2022-10-11T14:40:41.800784357Z \tat com.github.dockerjava.core.DefaultInvocationBuilder.get(DefaultInvocationBuilder.java:77) ~[docker-java-core-3.2.8.jar!/:na]\r\n2022-10-11T14:40:41.800787901Z \tat com.github.dockerjava.core.exec.InspectContainerCmdExec.execute(InspectContainerCmdExec.java:31) ~[docker-java-core-3.2.8.jar!/:na]\r\n2022-10-11T14:40:41.800792420Z \tat com.github.dockerjava.core.exec.InspectContainerCmdExec.execute(InspectContainerCmdExec.java:13) ~[docker-java-core-3.2.8.jar!/:na]\r\n2022-10-11T14:40:41.800795370Z \tat com.github.dockerjava.core.exec.AbstrSyncDockerCmdExec.exec(AbstrSyncDockerCmdExec.java:21) ~[docker-java-core-3.2.8.jar!/:na]\r\n2022-10-11T14:40:41.800798829Z \tat com.github.dockerjava.core.command.AbstrDockerCmd.exec(AbstrDockerCmd.java:35) ~[docker-java-core-3.2.8.jar!/:na]\r\n2022-10-11T14:40:41.800802249Z \tat com.github.dockerjava.core.command.InspectContainerCmdImpl.exec(InspectContainerCmdImpl.java:52) ~[docker-java-core-3.2.8.jar!/:na]\r\n```\r\n\r\nBased on the documentation, Docker uses a capability name with/without the CAP_ prefix interchangeably:\r\nhttps://docs.docker.com/engine/reference/run/\r\n\r\n\u003e The --cap-add and --cap-drop flags accept capabilities to be specified with a CAP_ prefix. The following examples are therefore equivalent:\r\n\u003e docker run --cap-add=SYS_ADMIN ...\r\n\u003e docker run --cap-add=CAP_SYS_ADMIN ...\r\n\r\nThis does not appear to be a Docker / Docker swarm bug.  Can the CAP_ prefix be automatically stripped to prevent the deserialization issue?\r\n\r\nThanks\r\n\r\n","author":{"url":"https://github.com/armband","@type":"Person","name":"armband"},"datePublished":"2022-10-13T13:58:34.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":14},"url":"https://github.com/1980/docker-java/issues/1980"}