Re: Bad file access on the rise

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux