canonical / canonical/workshop

`.workshop/` definition dir is writable from inside the container; `read-only` mount plug fixes it but relies on mount precedence

Open
#914 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
108
Forks
17
Avg merge
1d 7h
Merged PRs (30d)
40

Description

Since `/project` binds the whole project root into the workshop, the definition directory `.workshop/` is writable by the workshop user — including the definition YAML and any in-project SDK `setup-project` hooks. A process inside the workshop can edit its own definition and the changes are applied by the next `workshop refresh`. For hooks this means arbitrary code execution as the workshop user on refresh, since `setup-project` runs from the (writable) `.workshop//hooks/` as that user.

Quick repro (0.9.2, LXD 6.9):

```
$ workshop exec test -- sh -c 'touch /project/.workshop/canary; echo $?'
0
```

Declaring a read-only mount plug over the definition dir closes it — the definition becomes immutable from inside, while `workshopd` still manages it host-side:

```yaml
plugs:
lockdown:
interface: mount
workshop-target: /project/.workshop
read-only: true
```

After that:

```
$ workshop exec test -- sh -c 'touch /project/.workshop/canary; echo $?'
touch: cannot touch '/project/.workshop/canary': Read-only file system
1
$ workshop exec test -- mount | grep '.workshop'
... on /project/.workshop type ext4 (ro,relatime)
```

`workshop refresh` still works, and the mountpoint can't be renamed or removed from the rw parent ("Device or resource busy"), so it's self-reinforcing — the container can't unmount its own lock.

My question: is mounting `.workshop/` read-only over itself a supported pattern, or does it work only by nested-mount precedence over the core `/project` bind (i.e. could a future version break it)? If it's intended to work, having it documented — or the definition dir being read-only inside the container by default — would let people rely on it.

Contributor guide

Open the contributing guide

Research direction

Start by reproducing the documented `workshop exec` and `workshop refresh` commands with and without the `lockdown` mount plug, then inspect how mount plugs and the `/project` bind are handled. Done means establishing whether read-only mounting `.workshop/` is supported and stable, and documenting that behavior or making the definition directory read-only by default.

Written by the indexing model from the issue text.

Assessment

Tech stack
yaml
Domain
infrastructure, security
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.