On Friday, June 07, 2013 05:14:30 PM Lennart Poettering wrote:
On Fri, 07.06.13 09:50, Steve Grubb (sgrubb(a)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...