From: dominick.grift@gmail.com (Dominick Grift)
Date: Fri, 19 Oct 2012 20:13:19 +0200
Subject: [refpolicy] [REVIEW REQUEST] Changes to the pulseaudio policy
 module and its dependencies
In-Reply-To: <20121019180055.GA11667@siphos.be>
References: <1350667422-9219-1-git-send-email-dominick.grift@gmail.com>
	<20121019180055.GA11667@siphos.be>
Message-ID: <1350670399.12496.24.camel@d30.localdomain>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com



On Fri, 2012-10-19 at 20:00 +0200, Sven Vermeulen wrote:
> On Fri, Oct 19, 2012 at 07:23:42PM +0200, Dominick Grift wrote:
> > The pulseaudio_tmpfs_file_type is assigned to all clients tmpfile
> > file types separately with the pulseaudio_tmpfs_content() interface
> > 
> > pulseaudio_clients atomatically get the access they need to pulseaudio
> > tmpfs content
> > 
> > read and delete the content
> 
> 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

> Wkr,
> 	Sven Vermeulen
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy