/dev/shm permissions

[geez]

Suddenly, Chromium stopped working for me after several months of use!
Running it at terminal revealed it couldn't write to /dev/shm any
longer.

I chmod a+w /dev/shm and all is fine again. Is this a security risk?

What happened? How could the permissions change?

In /etc/fstab:

shm /dev/shm tmpfs
defaults,nodev,nosuid,noexec,rw 0 0

[Piotr Karbowski]

I have 777 for /dev/shm.

## fstab
tmpfs /dev/shm tmpfs nodev,nosuid,noexec 0 0
##

Maybe remove defaults?

[geez]

Yes, I actually just put 'defaults' back into /etc/fstab as a hack in
the dark. Terrible! It contradicts with nodev, noexec. Pointless. Your
fstab is correct.

I'm just concerned how suddenly the permissions could change to break
Chromium. What's going to break next? And where are these permissions
set? Should I umask in /etc/fstab?

[Piotr Karbowski]

I dont know you you have diffrent permissions than me, maybe you have
new udev or something? Check mode=777 to opts in fstab.

[geez]

Yeah, I'm going to keep /dev/shm world writeable with mode=777 for
now, but I'm curious about 'official' guidelines for it. Strange that
no one else experienced this...

[Piotr Karbowski]

What udev version you have?

% ls -ld /dev/shm
drwxrwxrwt 2 root root 40 01-10 11:49 /dev/shm

[geez]

I'm still running udev 135-r9.

[geez]

Found it. Re-emerging sys-apps/baselayout changes the permissions on /
dev/shm:

# ls -ld /dev/shm
drwxr-xr-x 2 root root 80 Jan 10 15:24 /dev/shm

Interesting...

On Jan 10, 3:21 pm, geez <geezoma...@gmail.com> wrote:
> I'm still running udev 135-r9.
>

> On Jan 10, 3:19 pm, Piotr Karbowski <jabberu256...@gmail.com> wrote:
>
> 257258

[geez]

Found it. Re-emerging sys-apps/baselayout changes the permissions on /
dev/shm:

# ls -ld /dev/shm
drwxr-xr-x 2 root root 80 Jan 10 15:24 /dev/shm

Interesting...

On Jan 10, 3:21 pm, geez <geezoma...@gmail.com> wrote:

> I'm still running udev 135-r9.
>

> On Jan 10, 3:19 pm, Piotr Karbowski <jabberu256...@gmail.com> wrote:
>
> 257258