Accessing Underlying Files in Worker Host

[mitchellkingsley]

Hey all,
I fully understand that the philosophy of Concourse is that it is stateless and should not be aware of the host that it is running on top of. However, there is a use case that I have in mind which accessing the underlying host would be very valuable.

The idea has been brought up before in the following issues and it was concluded that other than using sshfs, that it wasn't really possible:
#4241
#857

After poking around, a colleague and I found that the resolv.conf from the host is mounted in worker containers. Allowing you to leak information from the host into a worker by adding comments to resolv.conf. This is quite hacky, but does show that the worker isn't totally abstracted away from the host.

Output from pipeline:

selected worker: concourse
+ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda       8:0    0   30G  0 disk 
|-sda1    8:1    0 29.9G  0 part /etc/resolv.conf
|-sda14   8:14   0    3M  0 part 
`-sda15   8:15   0  124M  0 part 
sdb       8:16   0    8G  0 disk 
`-sdb1    8:17   0    8G  0 part 
sr0      11:0    1  628K  0 rom  
+ cat /etc/resolv.conf
domain n0bj13rk40guti2kf5w2u0gjxh.ux.internal.cloudapp.net
search n0bj13rk40guti2kf5w2u0gjxh.ux.internal.cloudapp.net
nameserver 168.63.129.16
;This is a leaked line! <---- Look!

This is all using the containerd backend. My hope is that someone might be able to provide a path to add another bind mount, allowing me to pass specific information from the host into the context of the worker without having to go through the hack of passing through resolv.conf.

Any thoughts?
Thanks.

[marco-m]

You can bypass all the containerization machinery with houdini.
See
https://concourse-ci.org/concourse-worker.html#configuring-runtimes
https://github.com/vito/houdini

If you go this route, a Linux worker becomes like a macoS or Windows one: a task has total direct access to the host, so be careful.

[spieden]

@marco-m Can you clarify how to directly access the worker's host filesystem when using houdini? I tried and noted a difference in the output of df as compared to containerd but can't see a way forward. It seems like bind mounts need to be passed to houdini such that they wind up here: https://github.com/vito/houdini/blob/master/container_linux.go#L50-L67

The df output for containerd:

selected worker: d3b38001d4ca
running df
Filesystem           1K-blocks      Used Available Use% Mounted on
overlay               41943040  27534572  12818804  68% /
tmpfs                    65536         0     65536   0% /dev
shm                    8108724         0   8108724   0% /dev/shm
/dev/loop2            41943040  27534572  12818804  68% /tmp/gdn-init
/dev/loop2            41943040  27534572  12818804  68% /scratch
/dev/loop2            41943040  27534572  12818804  68% /tmp/build/f227885a
/dev/loop2            41943040  27534572  12818804  68% /etc/hosts
/dev/loop2            41943040  27534572  12818804  68% /etc/hostname
/dev/loop2            41943040  27534572  12818804  68% /etc/resolv.conf
tmpfs                    65536         0     65536   0% /dev/null
tmpfs                    65536         0     65536   0% /dev/random
tmpfs                    65536         0     65536   0% /dev/full
tmpfs                    65536         0     65536   0% /dev/tty
tmpfs                    65536         0     65536   0% /dev/zero
tmpfs                    65536         0     65536   0% /dev/urandom

.. and for houdini:

selected worker: 075e52954142
running df
Filesystem           1K-blocks      Used Available Use% Mounted on
tmpfs                    65536         0     65536   0% /dev
/dev/loop2            41943040  27538568  12814904  68% /etc/resolv.conf
/dev/loop2            41943040  27538568  12814904  68% /etc/hosts
/dev/loop2            41943040  27538568  12814904  68% /scratch
/dev/loop2            41943040  27538568  12814904  68% /tmp/build/f227885a

[spieden]

Here's where the jail starts I believe: https://github.com/vito/houdini/blob/master/container_linux.go#L142-L144