Add dummy /proc/<pid>/setgroups

[stepancheg]

Buildah does not work in gVisor, it tries to write to /proc/<pid>/setgroups.

This PR does not fix it, but one step at a time.

The idea I'm pursuing is to allow writing allow to /proc/<pid>/setgroups without supporting deny.

[EtiennePerot]

The mode being fixed at 444 seems like it should reject writes though, at least when running as non-root within the sandbox. Should it be 644 and owned by the task's user?

Also, I'd assume that buildah is going to try to write deny to this file, or at least that's what I've seen all programs that write to this file due, as this is one of the restrictions in the "all of the following restrictions apply" list of setgroups(2) when then enables processes to later write to /proc/<pid>/uidmap and /proc/<pid>/gidmap.

I guess what I'm saying is that it would be better to first make sure buildah can get past the logical step that requires /proc/<pid>/setgroups (that being step probably being creating its own user namespace), before merging this PR as a step towards buildah support.

[stepancheg]

This PR only implements reading, so it is 444. When write implemented, it should be 644.

Linux permissions are:

ls -l /proc/self/setgroups
-rw-r--r-- 1 root root 0 Aug 14 01:37 /proc/self/setgroups

sudo -u mail ls -l /proc/self/setgroups
-rw-r--r-- 1 mail mail 0 Aug 14 01:38 /proc/self/setgroups

sudo -u mail ls -l /proc/1/setgroups
-rw-r--r-- 1 root root 0 Aug 13 01:08 /proc/1/setgroups

buildah seems to write allow by default

https://github.com/containers/storage/blob/main/pkg/unshare/unshare_linux.go#L207-L208

and if there is some option, it writes deny, I don't know, I did not dig. But it writes to this file unconditionally (except for another flag, which again I didn't dig).

I was thinking having this file won't harm and may help.

But I can try making buildah skip this step first.