Permission denied on shared memory segments in /dev/shm/

Question

in Ubuntu 20.04 I'm having problem with accessing shared memory segments by different users. The associated files are created using shm_open() with the combination of O_CREAT and O_RDWR flags and placed in /dev/shm. I have the following rxample program:

#include <stdio.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <string.h>
#include <errno.h>

int main()
{
        int ret = 0;
        errno = 0;
        ret = shm_open("/testshm", O_CREAT | O_RDWR, 00666);
        fprintf(stderr, "return value %d\n", ret);
        fprintf(stderr, "result %d: %s\n", errno, strerror(errno));

        return 0;
}

When I run it for the first time, it works as expected and /dev/shm/testshm is created:

$ ls -la /dev/shm
total 0
drwxrwxrwt  2 root   root     60 Aug  3 16:34 .
drwxr-xr-x 18 root   root   4580 Aug  3 12:41 ..
-rw-rw-r--  1 krejci krejci    0 Aug  3 14:37 testshm

Then running program again as the same user works fine, but when I try to run the program as root, I'm getting "Permission denied":

# id
uid=0(root) gid=0(root) groups=0(root)
# ./test
return value -1
result 13: Permission denied

• The same code works fine in other Linux distro as well as in Ubuntu 19.10.
• When the O_CREAT flag is not present in subsequent program invocation, it also works fine.
• I didn't find anything useful in the logs.
• disabling AppArmor doesn't help

Solution

This is caused by a change to the Linux kernel in 4.19 for added security.

You can change the behaviour of the kernel back to the old way by running:

sudo sysctl fs.protected_regular=0

Comments

[KGIII]

You might find this question to be more appropriate here. It looks to be more a programming question than an Ubuntu-specific question. The mods frown on cross-posting (posting the same question at multiple SE sites), but you can request that it be moved. Someone here may know, but you might get better information over there.

[Radek Krejci]

@KGIII Thanks, I'm not sure if it is really about programming since the problem is only on Ubuntu 20.04. It can be possibly connected with tmpfs setup, ubuntu's specific root handling or something else which is specific to Ubuntu.

[KGIII]

Yeah, it's one of those questions that's not off-topic - it's very much about Ubuntu, but it might get more knowledgeable eyes at a more programming-centric. If you don't get an answer, someone over there may know better. (If I knew, I'd have already answered.)

[user3629249]

from the MAN page for shm_open() the object's permission bits are set according to the low-order 9 bits of mode, except that those bits set in the process file mode creation mask (see umask(2)) are cleared for the new object. What is your umask set to?

[user3629249]

I'm running ubuntu linux 18.04. My umask is 0022. I ran the posted code with no problems. I then ran the posted code as root. The code worked perfectly each time. Therefore, I suspect the problem is with OS version 20, unless your umask is generating the problem

[user3629249]

when you ls -al on the /dev/shm/... what are you getting for a result? given my umask the result is: -rw-r--r-- 1 richard richard 0 Aug 5 17:07 testshm `

[Radek Krejci]

@user3629249 it is in the question, the result is -rw-rw-r-- 1 krejci krejci 0 Aug 3 14:37 testshm. But why the root user should be limited by any access rights? And yes, it is fine till Ubuntu 19.10 (and some other distros, like openSUSE), the only distro where I have this problem is Ubuntu 20.04.

[user3629249]

are you sure you are actually logged in as root? Are you using sudo to execute your program? details are needed.

[user3629249]

I have now run the posted code under ubuntu linux 20, both as myself and as 'root' in both cases it worked perfectly. Both cases output: return value 3 result 0: Success

[Radek Krejci]

@user3629249 It is already written in the original question. I'm pretty sure I'm root, see the id(1) output. Did you modified the posted code somehow? Because adding shm_unlink() make it work since the testshm file is being removed and creating it again then works. What does not work for me is opening already existing file. Could you please try to repeat all the steps I did ($ ./test; $ ls -la /dev/shm; $ sudo su; # id; #./test) and compare the results with mine? I'm testing in virtualbox with fresh installation and all the updates installed.

[user3629249]

DO NOT remove the original posted code. Many of the comments were directly related to that code.

[Radek Krejci]

What have I changed? You can check the revision history to see that I've edited the question just once by adding a note about AppArmor. That's not my fault that you did not read the whole question and ask me repeatedly for the information already present in the original question. And to have the info also here - you are not running it on Ubuntu 20.04 (details as a comment to your answer below), so it is working as expected.

[Radek Krejci]

But then the example app wouldn't demonstrate the problem. I don't want to remove the shared memory object, I want to keep it there for others. The problem is, that in the case it is there, the other users are not able to access it despite the mode (access permissions) it was created with. And the same applies even to the root user.

[Radek Krejci]

I'm afraid that you are still on bionic (18.04) or xenial (16.04) - people.canonical.com/~kernel/info/kernel-version-map.html. Focal's (20.04) kernel version is 5.4. The issue is related only to Ubuntu 20.04.

[user3629249]

@RadekKrejci. Thanks for letting me know. I performed: `sudo apt-get update; sudo apt-get upgrade; in a terminal window which resulted in LOTS of downloads and installs. I expected that to have updated to ubuntu linux 20.04

[user3629249]

I finally had to force the upgrade via: sudo do-release-upgrade -d

[einpoklum]

Can you please elaborate on what that flag means, exactly?