Bad file access on the rise

Lennart Poettering mzerqung at
Fri Jun 7 15:48:39 UTC 2013

On Fri, 07.06.13 11:44, Steve Grubb (sgrubb at wrote:

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

Actually all libpulse clients do this.

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

But why? This stuff should be simple, and it's always a better idea to
simply let the kernel do EACCES rather then trying to be smarter than
the kernel and reimplement access control in userspace.

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

shmctl() is SysV shared memory. /dev/shm is POSIX shared memory. So, no,
it wouldn't help. And IPC_RMID is in no way nicer than unlink() of a
file. Both are invitations for leaving dead files around. They are both
badly designed interfaces.


Lennart Poettering - Red Hat, Inc.

More information about the devel mailing list