Salsa CI introducing world-writable permissions

[John Goerzen <jgoerzen@complete.org>]

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!