new shared-memory interface causes /dev/shm/<snap> dir to have world-write permissions

[Jamie Strandboge]

The new zoom-client revision uses the new shared-memory interface. Before this upgrade, I observed that /dev/shm/snap.zoom-client was present and was root:root 0755 (though apparently the snap didn't actually use it). After the upgrade, it is root:root 0777:

$ ls -ld /dev/shm
drwxrwxrwt 3 root root 60 Apr 21 07:43 /dev/shm

$ snap version
snap 2.55.3
snapd 2.55.3
series 16
ubuntu 20.04
kernel 5.4.0-107-generic

$ snap list zoom-client
Name Version Rev Tracking Publisher Notes
zoom-client 5.10.3.2778 175 latest/stable ogra -

The previous revision of zoom-client was 170.

Note, if debugging this, you may need to first:
$ snap refresh zoom-client
$ sudo /snap/snapd/current/usr/lib/snapd/snap-discard-ns zoom-client
$ sudo rmdir /dev/shm/snap.zoom-client/

otherwise zoom-client going from 170 to 175 fails to start (write(2,
"[0421/074431.324810:FATAL:platform_shared_memory_region_posix.cc(255)] This is frequently caused by incorrect permissions on /dev/shm. Try 'sudo chmod 1777 /dev/shm' to fix.\n", 175 <unfinished ...>). I believe that ogra may be filing a bug for this (appears to be a race). This was discussed in #snappy on irc on 2022-04-21 12:46 UTC.

[Alex Murray (alexmurray)]

Hmm it looks like this was (un)intentional if I am reading this correctly - https://github.com/snapcore/snapd/commit/2dd614a92b15d0052d04af1682bb778dc134f947#diff-5f9470adea92e967613bf2333af9c9c47d71f9c58cd423206f56ac673d40d41cR90

[James Henstridge (jamesh)]

The intent was to create the directory with perms 01777, the same as /dev/shm. There seems to be something going wrong where the sticky bit is lost in some situations. I haven't tracked down the cause yet.

[Oliver Grawert (ogra)]

i (and severeal other users that notified me) can reproduce this behaviour, marking as confirmed ...

[James Henstridge (jamesh)]

I've tracked down why the sticky bit is not being applied. In the MkDir() function, it passes "uint32(perm.Perm())" as the third argument to the mkdirat() syscall:

https://github.com/snapcore/snapd/blob/5b97b04f7d112480603face09a9da0ad3018d6fd/cmd/snap-update-ns/utils.go#L183

This is equivalent to "uint32(perm & 0777)", which strips the sticky bit from what we asked it to create.

I've also noticed some cases where the directory ends up with 0755 permissions, which I haven't yet tracked down, but seem to happen when updating an existing mount namespace.

[James Henstridge (jamesh)]

I think the 0755 permissions are due to the umask snapd invokes snap-update-ns with during an update of existing mount namespaces.

While snap-confine explicitly sets the umask to 0 while invoking snap-update-ns, snapd does not. So snapd's 022 umask would explain the difference.

I think the right fix for the problem would be to:

1. remove the .Perm() method calls in utils.go

2. make snap-update-ns set its umask to 0.

[James Henstridge (jamesh)]

I've created a PR to address this issue here:

https://github.com/snapcore/snapd/pull/11729