Hi folks,
I thought I ought to alert people about this, since I haven't seen it documented anywhere. Salsa CI is effectively doing a chmod -R a+w . on
trees in checks out, and in some circumstances these permissions can
flow into generated data (.debs, Docker images, etc.)
I recommend adding a chmod -R go-w . to all pipelines right now. The
standard Debian pipelines at
https://salsa.debian.org/salsa-ci-team/pipeline/ don't seem to be doing that, unfortunately. Hopefully most of the
standard tooling forces permissions on install steps, but I would
imagine not all of it does.
I submitted an issue at
https://salsa.debian.org/salsa/support/-/issues/284 and I'm including it
below in case it's helpful.
Hello,
I have several Salsa CI pipelines building Debian Docker images.
On one of them, I noticed systemd warning about world-writable permissions on a file that had been copied into /etc/systemd/system. Weird. It didn't do that when I used the image I built locally.
Upon investigating the situation, I found that salsa was effectively running
chmod -R go+w .
on the checkout.
This introduced security vulnerabilities because in Docker, COPY transferrs those permissions to the generated image. Various deb-building approaches could do this also.
Here's how I pinned this down to Salsa.
In the relevant repo, I could type:
```
$ git ls-tree 91df28f0cc4b0d58cfda57fc1cc5c350bdbaf76d -- service/
100644 blob ec429c0bbdb50da81ba0fbef5fc516fc5dc5791f service/nncp-caller.service
100644 blob af287bb8255a1fbb774777d56b17b32178dd712e service/nncp-daemon.service
100644 blob 13201ad7b83ba30cd0370060aede9bd9f5f5893d service/nncp-toss.service
```
There - mode 0644.
I added a `ls -lR` step to the job, so you can see what it looks like at the start of my job in Salsa here:
https://salsa.debian.org/jgoerzen/docker-nncp/-/jobs/2439096
```
drwxrwxrwx 2 root root 4096 Feb 6 06:50 service
...
./service:
total 12
-rw-rw-rw- 1 root root 165 Feb 6 06:50 nncp-caller.service -rw-rw-rw- 1 root root 165 Feb 6 06:50 nncp-daemon.service -rw-rw-rw- 1 root root 179 Feb 6 06:50 nncp-toss.service
```
It does not appear to be a umask issue; the umask was 0022 as it should be.
I added a:
chmod -R og-w .
to the job which seems to have fixed this issue, but I'm not sure if that is really a permanent fix or why this was happening.
Thanks!
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)