[refpolicy] [REVIEW REQUEST] Changes to the pulseaudio policy module and its dependencies

[sven.vermeulen@siphos.be (Sven Vermeulen)]

On Fri, Oct 19, 2012 at 08:13:19PM +0200, Dominick Grift wrote:
> > I have a similar construction with alsa. One thing I am hoping to look into
> > soon is a "What if /dev/shm was shm_tmpfs_t instead of tmpfs_t", would that
> > make sense?
> > 
> > It would tighten the scope of such "wide" tmpfs file accesses.
> 
> pulseaudio clients create that pulse-shm file in /dev/shm with a private
> type, i do not see how this would help?
> 
> programs that use pulse and that run in the userdomain create those
> files with user_tmpfs_t
> 
> So all they need with regard to tmpfs_t is search tmpfs_t dirs, add and
> remove dir entries from tmpfs_t dirs and get attributes of tmpfs_t
> filesystems

It's mainly for reducing the scope. If pulseaudio clients automatically have
their tmpfs types be writeable by other pulseaudio clients, then also
non-shm related tmpfs files are affected by this.

If we'd use a specific type for shared memory (like shm_t) then other tmpfs
files are not "opened up".

It's a fairly intrusive change for a small gain, I understand (many policies
will need to be adapted for this, whereas there aren't that many tmpfs
locations on a system I think that are actually labeled as tmpfs_t). Hence
the "look into" part of the suggestion ;)

Wkr,
	Sven Vermeulen