/dev/shm keeps getting reset to rwxr-xr-t

Bug #559545 reported by Gavin Panella
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
apparmor (Ubuntu)
Invalid
Undecided
Jamie Strandboge

Bug Description

Something keeps changing the permissions on /dev/shm to 1755 every so often (maybe every boot, but I reboot infrequently enough that I can't be sure of this). This causes Chromium and Chrome (the browsers) to crash when rendering a page. Manually setting the permissions with "sudo chmod go+w /dev/shm" fixes this. Unfortunately I have no idea what is causing this.

Description: Ubuntu lucid (development branch)
Release: 10.04

Revision history for this message
Gavin Panella (allenap) wrote :

I purged apparmor and this issue has gone away.

affects: ubuntu → apparmor (Ubuntu)
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Gavin, what made you believe this was an AppArmor issue? AFAICS, there is nothing in AppArmor that would change the permissions on your /dev/shm directory. For example, I have AppArmor installed and my /dev/shm directory is 1777.

Do you use libvirt for virtualization? If so, did you use the 0.7.7 packages in my ppa and put your virtual machines into /dev/shm?

Changed in apparmor (Ubuntu):
assignee: nobody → Jamie Strandboge (jdstrand)
status: New → Incomplete
Revision history for this message
Gavin Panella (allenap) wrote :

Jamie, the reason I suspected apparmor was twofold. First I grepped
for dev/shm in /etc, found some likely looking files in
/etc/apparmor.d and then set about purging apparmor to see if it was
the problem.

The results I saw (from fgrep dev/shm -r .) contained:

  ./apparmor.d/abstractions/audio:/dev/shm/ r,
  ./apparmor.d/abstractions/audio:owner /dev/shm/pulse-shm* rwk,
  ./apparmor.d/abstractions/libvirt-qemu: /dev/shm/ r,
  ./apparmor.d/abstractions/libvirt-qemu: /dev/shm/pulse-shm* r,
  ./apparmor.d/abstractions/libvirt-qemu: /dev/shm/pulse-shm* rwk,

Secondly, after removing apparmor and rebooting, the problem went
away.

However, while writing this message and repeating the grep in a backup
I realise / remember that I did also remove some qemu and libvirt
packages at the same time, as well as virtualbox; I don't run any VMs
at the moment. Your question about libvirt has struck a chord.

(Also, wrt virtualbox, I remember following some instructions from
Jono Bacon's blog - iirc - maybe 6-12 months back. ISTR that involved
adding a PPA; could that have been yours?)

I don't know what more information I can add to this bug now. It
sounds like it could be invalid, but I'm happy to help reproduce if
it's still of interest.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

The /dev/shm items in /etc/apparmor.d are AppArmor profile abstractions-- for AppArmor profiles that use these abstractions, they only grant access to the files you see. They do not change permissions of the files in any way. An application may do this. My ppa is https://launchpad.net/~jdstrand/+archive/ppa/+packages and it contained libvirt 0.7.7 packages.

I asked the question because some people like to put virtual machines in /dev/shm and libvirt 0.7.7 will change permissions of files., and libvirt uses AppArmor. If you only ever installed libvirt from Ubuntu (latest is 0.7.5), then libvirt is not to blame. Can you check to see what version of libvirt you had installed?

Revision history for this message
Gavin Panella (allenap) wrote :

/var/log/apt/history.log shows that I removed libvirt0 (0.7.5-5ubuntu21) at around the same time as apparmor, so it looks like that's not the culprit. (Thanks for the explanation btw.)

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

The only other thing I can think of is that this is perhaps virtualbox. Since I've confirmed via source code inspection that this is not an AppArmor bug, but I don't know where to assign it to, I am going to mark the bug as 'Invalid'. If you discover what was actually changing the permissions of /dev/shm, please put back to 'New' and reassign to the appropriate package. Thanks for filing the bug.

Changed in apparmor (Ubuntu):
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.