On Friday, June 07, 2013 05:14:30 PM Lennart Poettering wrote: > On Fri, 07.06.13 09:50, Steve Grubb (sgrubb@xxxxxxxxxx) 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... -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
