Bad file access on the rise

[Steve Grubb]

On Friday, June 07, 2013 05:48:39 PM Lennart Poettering wrote:
> On Fri, 07.06.13 11:44, Steve Grubb (sgrubb at redhat.com) 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?

So that you are not filling up the audit logs. There are people that have to 
use these audit rules and we need a normally operating system to produce as 
few false positives as possible.


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

Well, you are already trusting the name. Who's to say some rougue process 
didn't create the file name to try and trick pulseaudio? How about doing like 
some processes do in the /tmp dir...put the segments in a directory 
/dev/shm/<user name>/ and then scan all the files that belong to that user?

There are ways to make this better if you are willing.  :-)

Thanks,
-Steve