Update documentation to clarify REPL usage and security implications

[swizzlr]

Update documentation to clarify REPL usage and security implications

[swizzlr]

error: failed to launch REPL process: process launch failed: 'A' packet returned an error: 8

[andradei]

Had to add --privileged like @LoiKos mentioned. Maybe it is time to update the README that is shown on https://hub.docker.com/_/swift/

[aduermael]

@hamin @gabhi You can use --security-opt seccomp=unconfined instead to disable seccomp. It's a little more secure. :)

docker run -it --security-opt seccomp=unconfined --name swiftfun swiftdocker/swift:latest /bin/bash

[LoiKos]

Hello, I download the latest official swift image from docker hub and there is still the problem with REPL.

mbp-de-loic:Orange loik$ docker run --cap-add sys_ptrace -ti --rm swift swift 
error: failed to launch REPL process: process launch failed: 'A' packet returned an error: 8

mbp-de-loic:Orange loikos$ docker images swift
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
swift               latest              d505ae70cb39        2 weeks ago         1.15 GB

Can't make it work even using --cap-add sys_ptrace but it work with --privileged

@swizzlr @hamin

[jonauz]

So what is the way to make this docker work? As I keep getting error: failed to launch REPL process: process launch failed: 'A' packet returned an error: 8 no matter what I try to copy from here to my terminal.
Can't pass even first step to install this docker. I'm not familiar with REPL, so definitely have no clue how to set up it, just following readme, which is not working.

[CarlitosDroid]

In the same way as @LoiKos and @andradei
I had to add --privileged
docker run --privileged --cap-add sys_ptrace -it --rm swift:5.0-xenial swift
I have Docker running on macOS Mojave. We are in 2019 and they still don't update the README in docker Hub.

[Guang1234567]

As @tianon comment for --privileged

maybe

docker run --cap-add sys_ptrace --security-opt seccomp=unconfined -it --rm swift swift

better than

docker run --privileged --cap-add sys_ptrace -it --name swiftfun swift /bin/bash

[tianon]

Ok, here's what I've had success with: (where default.json comes from https://raw.githubusercontent.com/docker/docker-ce/v17.06.2-ce/components/engine/profiles/seccomp/default.json)

--- default.json	2017-09-08 15:02:37.061507178 -0700
+++ swift.json	2017-09-08 15:02:54.821989684 -0700
@@ -216,6 +216,7 @@
 				"open",
 				"openat",
 				"pause",
+				"personality",
 				"pipe",
 				"pipe2",
 				"poll",

$ docker run -it --rm --security-opt seccomp=swift.json --cap-add sys_ptrace swift swift
Welcome to Swift version 3.1 (swift-3.1-RELEASE). Type :help for assistance.
  1>  

[Guang1234567]

[CorcovadoMing]

I have this issue too (on clean install ubuntu 14.04 VM),
But I found that if I add the --privileged to docker command, it works
otherwise I got error: failed to launch REPL process: process launch failed: 'A' packet returned an error: 8

[aduermael]

@tianon @swizzlr @hamin that works:

docker run --cap-add sys_ptrace -ti --rm swiftdocker/swift swift

[swizzlr]

We need a third person to try this out to figure out which of our machines is wrong. The image ID is c9f6b5fece4f, what's yours?

[swizzlr]

I'd suggest we document this in the README, since we don't have any power over this right now, then close this issue.

[tianon]

Indeed -- --privileged is a huge hammer, and should be used with extreme caution and care. It'd be useful IMO to narrow down exactly which part of Docker's default seccomp profile is causing the denial, especially so either the debugger can be fixed to not require that (if possible) or a custom profile to allow it can be written (to avoid using a bare unconfined). 👍

[swizzlr]

@tianon thanks for the tip. we know it's something to do with accessing keyboard drivers in LLDB, but we might have more luck following up on their mailing list. In any case, REPL support is something rarely requested – most devs have their own local install of Swift that works just fine for that. It would be very nice to have a permanent solution.

[tianon]

Sounds like more caps are now required than before -- definitely time to update the description, but we need to figure out the minimal set of required caps first (because adding "--privileged" to that description is a 100% no-go; you might as well not use a container at that point).

[hamin]

The real was definitely working for me, but I was installing all the deps that apple was suggesting. Should we put those deps back for completeness sake? We might be breaking other parts of the toolchain without knowing it but not having deps apple details in their docs. Perhaps revert that commit and see what happens?

[swizzlr]

@hamin When they say "development dependencies" I assume they mean for building the swift toolchain itself. (right, @jckarter)? I'll work backwards from the list of dependencies and find which libraries are necessary; then I'll open a PR to the swift repo updating their docs.

[hamin]

@swizzlr yeah what you're saying makes sense, checking it out

[swizzlr]

@hamin just tried "reverting" those changes and no dice. are you sure it worked for you, back then? maybe it's flaky?

[hamin]

So its working for me right now. I'm running latest master:

[hamin]

@swizzlr its working for me. I'm running latest master

[hamin]

@swizzlr what were you trying to run exactly?

[hamin]

@swizzlr argh sorry its not running for me...i was running my old docker image...gimme a few

[hamin]

@swizzlr confirmed this master is not working for me...the above screenshot was from my original repo. It definitely worked

[swizzlr]

Does this commit work 369c495 ?

[hamin]

@swizzlr checking it out. Meanwhile do a docker pull from here https://hub.docker.com/r/harisamin/docker-swift/

docker pull harisamin/docker-swift

Try that and see if it works there

[swizzlr]

Nope, not working on this (digital ocean VM hooked up with docker-machine).

docker run -it harisamin/docker-swift bash

[hamin]

wtf how is it working for me then from my original image. you're just typing swift right? I know there's a swift_repl not sure what exactly that one does

[hamin]

The one I pushed to Docker Hub earlier today was this: harisamin/docker-swift latest 48660452cc49

[hamin]

Again from original one I had.

[hamin]

@swizzlr master on our repo:

Step 7 : RUN wget https://swift.org/builds/ubuntu1404/swift-2.2-SNAPSHOT-2015-12-01-b/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04.tar.gz
 ---> Running in 0e5501001ce0
--2015-12-04 00:32:30--  https://swift.org/builds/ubuntu1404/swift-2.2-SNAPSHOT-2015-12-01-b/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04.tar.gz
Resolving swift.org (swift.org)... 169.45.67.140
Connecting to swift.org (swift.org)|169.45.67.140|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2015-12-04 00:32:30 ERROR 404: Not Found.

Checking if there's a new tar, maybe apple removed the old one

[hamin]

@swizzlr lol the link is dead: https://swift.org/builds/ubuntu1404/swift-2.2-SNAPSHOT-2015-12-01-b/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04.tar.gz

Got it from here: https://swift.org/download/

[lxcid]

On my own docker implementation I had user reporting the same issue. Funny thing is it work for my docker on VM.

[swizzlr]

@lxcid That's fascinating! Do you think you could find out what the implementations are?

Maybe this is a TTY thing?

---

I was interested in creating a latest image that would provide the most recent version built from source. Perhaps if we try building from scratch inside the container we might unearth the dependencies that are not present?

[lxcid]

I'm trying to build from source at the moment though. Its painfully slow, maybe its because I'm building a release build.

Use the following python (2.7) script https://github.com/apple/swift/blob/master/utils/build-script

I'm not sure if I can wait until it complete but I'll keep you updated on my finding.

[lxcid]

root@ab75a4cb7eff:/usr/src/swift# ./build/Ninja-ReleaseAssert/swift-linux-x86_64/bin/swift --version
Swift version 2.2-dev (LLVM 46be9ff861, Clang 4deb154edc, Swift c959ce2c83)
Target: x86_64-unknown-linux-gnu
root@ab75a4cb7eff:/usr/src/swift# ./build/Ninja-ReleaseAssert/swift-linux-x86_64/bin/swift          
LLVM ERROR: Compiler-internal integrated REPL unimplemented for this platform

This is the output of the release build.

I'm doing another debug build at the moment.

[hamin]

@lxcid do u mind trying the latest master? I've tested the current master on my local docker instances and am able to launch the repl without issue. Let us know :)

[lxcid]

I just tried the latest master fb7ff42 but it still have the same error in Digital Ocean docker.

I suspect it is the binary that have issue.

[swizzlr]

@hamin you running it on your MB in boot2docker?

[hamin]

I installed docker via their official mac DMG.

sh --login '/Applications/Docker/Docker Quickstart Terminal.app/Contents/Resources/Scripts/start.sh'

That's how i start it its funny because looking at #12 seems like @sosedoff was able to deploy our image and it seems to be running.

[sosedoff]

Im running swift docker image: swiftdocker/swift:836d5b4ca56e and it works fine on both linux and osx machines. Locally (on osx) im using docker-machine and can run REPL with this command:

$ docker run -it swiftdocker/swift swift
Welcome to Swift version 2.2-dev (LLVM 46be9ff861, Clang 4deb154edc, Swift 778f82939c). Type :help for assistance.
  1>

[swizzlr]

I'm laboriously downloading the entire thing to my local machine now, but I think we might be able to isolate this to digitalocean. Curious, but not worth leaving in the open without more reports.

[swizzlr]

I can confirm it works locally!

This is so weird.

Works locally on OS X. Failed on EC2.

https://hub.docker.com/r/swiftdocker/swift/
https://hub.docker.com/r/ontouchstart/docker-swift-snapshot/ (my own docker image)

Local OS X docker machine

EC2

[lxcid]

@CorcovadoMing awesome find! I can confirm that --privileged=true fixed it. I still like to know whats wrong though. I going to do some more investigation.

[hamin]

@CorcovadoMing Awesome find! Would be great to know what's causing this. If its something we can fix in our docker configuration I'm game :). @CorcovadoMing @lxcid feel free to submit PR :)

[swizzlr]

It seems that we may need to fix swift, it may be attempting to access hardware that it isn't allowed to find.

[CorcovadoMing]

As you can see, there is no problem with interpreted the swift file without lldb via swift *.swift and also compiled with swiftc command in docker without --privileged=true

lldb seems to need to access the bottom layer to provide the runtime information

is it possible that we manually disable the lldb debugger to run swift repl?
for now, I think the whole swift repl is built on top of lldb, so there are not much thing we can do on docker configuration

[swizzlr]

You can't run interactive swift without lldb, I've tried. Seems we need to figure out what lldb needs at the machine level.

--privileged worked for me

sudo docker run --privileged  -it ontouchstart/docker-swift-snapshot

[13rac1]

If anyone else is looking, this issue is already listed on the swift bug tracker: https://bugs.swift.org/browse/SR-54

[hamin]

Fixed by #24

[tianon]

@aduermael niiiice, I've confirmed that's working here too! That's way better. 🤘

[swizzlr]

@tianon @aduermael Thanks so much Adrian! I will fold this into the documentation.

[swizzlr]

So, to run the REPL we need to add the sys_ptrace key which allows you to "Trace arbitrary processes using ptrace(2)."

https://docs.docker.com/engine/reference/run/#/runtime-privilege-and-linux-capabilities

Now we just need to figure out how necessary that is, and if the REPL can run without it!

[aduermael]

The Swift.org community makes use of the LLDB debugger to provide a rich REPL as well as the debugging environment for the Swift Language

@swizzlr the REPL uses LLDB, and LLDB needs ptrace...

https://swift.org/lldb/#why-combine-the-repl-and-debugger

[hamin]

this one is tough and has been haunting us forever :) . Not sure what to do here, in the Github readme we have privileged noting that ppl use containers locally for development too and not just for deployments, places where a Swift repl is more needed or helpful. I think we decided to exclude them from the Docker hub documentation specifically for containers on linux servers concern. I think this was also pointed to us out by Docker team when we were merging the project in the official images section that they maintain.

[aduermael]

@tianon

Sounds like more caps are now required than before

Unfortunately, even with --cap-add=ALL, I can't make it work... 😕

[tianon]

Ah, so there's likely something in the default seccomp profile and/or apparmor profile blocking it now.

[tianon]

Confirmed, I can run the REPL with just "--security-opt seccomp=unconfined" (and no other options). Now to narrow down what exactly is required for it to work that the default profile blocks.

[Khalian]

Should we even be supporting repl in the official image? If things like text editors are excluded, everything except the core compiler and runtime should be excluded right? The purpose of this image is execution, not dev support.

[swizzlr]

@jonauz If the Readme instructions aren't working for you, please open a separate issue. This issue tracks the fact that the REPL fails without elevated security privileges.

[swizzlr]

Action item: me to update Readme and sync it with official repo README.

[fekerr]

I get this:

docker run --cap-add sys_ptrace -it --rm swift swift
error: failed to launch REPL process: process launch failed: 'A' packet returned an error: 8

I see from above I should perhaps open a new issue?

[tianon]

@fekerr it likely also needs a slightly customised seccomp profile, as I noted above (#9 (comment))

[shahmishal]

@swizzlr We are moving Swift Docker issues to https://bugs.swift.org Component: Docker. Can you please file your issue on bugs.swift.org?

We are planning on closing GitHub swift-docker issues on Dec 20th, 2018 (PST).

[tianon]

Adding --privileged is a huge hammer with broad security implications. What should be documented is the specific security features that need to be disabled, add I already noted above: #9 (comment)

[1oo7]

When I add --cap-add sys_ptrace the image never gets created.

[DrSajid]

Hi,

I just tried today and this worked for me!
docker run --privileged --cap-add sys_ptrace -it --name swiftfun swift /bin/bash

[NHellFire]

I've gotten it working with only one change to the seccomp profile.

root@2b7a2030895e:~# strace -f swift repl 2>&1 | grep EPERM
[pid   436] setsid()                    = -1 EPERM (Operation not permitted)
[pid   439] personality(PER_LINUX|ADDR_NO_RANDOMIZE) = -1 EPERM (Operation not permitted)

My change to the default seccomp profile:

--- seccomp.json.orig  2023-08-31 03:56:06.480864664 +0100
+++ seccomp.json  2023-08-31 03:56:51.149223795 +0100
@@ -824,6 +824,19 @@
           "CAP_PERFMON"
         ]
       }
+    },
+    {
+      "names": [
+        "personality"
+      ],
+      "action": "SCMP_ACT_ALLOW",
+      "args": [
+        {
+          "index": 0,
+          "value": 262144,
+          "op": "SCMP_CMP_EQ"
+        }
+      ]
     }
   ]
 }
\ No newline at end of file

$ docker run --rm -it --security-opt seccomp=seccomp.json swift swift repl
Welcome to Swift version 5.8.1 (swift-5.8.1-RELEASE).
Type :help for assistance.
  1> import Foundation
  2> Date()
$R0: Foundation.Date = 2023-08-31 02:43:28 GMT
  3> ^D

Allowing ADDR_NO_RANDOMIZE by default was requested in moby/moby#43011, but the answer was to maintain your own seccomp profile.