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!