Bad file access on the rise

[Simo Sorce]

On Fri, 2013-06-07 at 17:14 +0200, Lennart Poettering wrote:
> On Fri, 07.06.13 09:50, Steve Grubb (sgrubb at redhat.com) wrote:
> 
> > Let's look at one of these pule-shm events:
> > # ausearch --start today -k access -f pulse-shm -i --just-one
> > ----
> > type=PATH msg=audit(06/07/2013 07:13:46.377:215) : item=0 name=/dev/shm/pulse-
> > shm-3756395503 inode=25089 dev=00:10 mode=file,400 ouid=gdm ogid=gdm rdev=00:00 
> > obj=system_u:object_r:user_tmpfs_t:s0 
> > type=CWD msg=audit(06/07/2013 07:13:46.377:215) :  cwd=/ 
> > type=SYSCALL msg=audit(06/07/2013 07:13:46.377:215) : arch=x86_64 syscall=open 
> > success=no exit=-13(Permission denied) a0=0x7fffbeda83c0 a1=O_RDONLY|
> > O_NOFOLLOW|O_CLOEXEC a2=0x0 a3=0x0 items=1 ppid=2369 pid=2370 auid=sgrubb 
> > uid=sgrubb gid=sgrubb euid=sgrubb suid=sgrubb fsuid=sgrubb egid=sgrubb 
> > sgid=sgrubb fsgid=sgrubb ses=2 tty=(none) comm=pulseaudio 
> > exe=/usr/bin/pulseaudio subj=unconfined_u:system_r:unconfined_t:s0 key=access 
> > 
> > So, gdm is creating a file 400 and pulse-audio can't open it. Is it suppose to 
> > be like that?
> 
> Yes, it is.
> 
> POSIX shared memory doesn't define any useful scheme for automatic
> removing of shared memory segments from /dev/shm after use. Hence, in
> order to make sure that left-over segments don't fill up /dev/shm
> forever PA will try to GC dead segments from /dev/shm on each
> start-up. For that it iterates through /dev/shm/pulse-shm*, tries to
> read the PID that is stored in there. When the PID still exists it goes
> to the next file. If the PID doesn't exist it unlinks the file and then
> goes to the next one. It's a simple scheme that works around the
> limitations of POSIX shm. Of course /dev/shm is a single namespace for
> all users, hence not all files can be opened, and that's totally cool
> and expected, and they will be skipped.
> 
> Shared memory on Linux is a mess. Not automatic clean up, no quota
> limits, it's a sad story. If you care about security and reliability, it
> would be great doing something about this, so that arbitrary users
> cannot DoS the system this easily anymore...

Any reason why the PID is not part of the file name so you do not have
to open files just to find out who owns them ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York