Bad file access on the rise

[Steve Grubb]

On Friday, June 07, 2013 05:14:30 PM 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.

88 times? Something changed. It didn't used to be this bad. Its doing this 
over and over on the same file it was denied access on previously.


> 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. 

Maybe the uid can be encoded in the name so that wrong uid's are skipped?


> 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, 

shmctl(<id>, IPC_RMID    doesn't help?

-Steve

> 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...