From: dwalsh@redhat.com (Daniel J Walsh)
Date: Wed, 03 Aug 2011 09:56:04 -0400
Subject: [refpolicy] [PATCH/RFC] Add support for the skype_t domain
In-Reply-To: <20110803134256.GB9734@siphos.be>
References: <20110724153808.GA25350@siphos.be> <4E32AEB5.2030100@tresys.com>
	<20110803134256.GB9734@siphos.be>
Message-ID: <4E395374.6040105@redhat.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/03/2011 09:42 AM, Sven Vermeulen wrote:
> On Fri, Jul 29, 2011 at 08:59:33AM -0400, Christopher J. PeBenito
> wrote:
>> On 07/24/11 11:38, Sven Vermeulen wrote:
>>> The skype application is a popular voice and video chat
>>> application. This patch adds preliminary support for skype on
>>> SELinux.
> [...]
>>> +userdom_manage_user_home_content_dirs(skype_t) 
>>> +userdom_manage_user_home_content_files(skype_t)
>> 
>> Is this really necessary since there is skype_home_t?
> 
> Depends on the use case, but Skype can be used to send and receive
> files, so skype_t needs to be able to manage the users' home
> directory content.
> 
> Not that I'm happy with that, but it seems to be how most
> applications handle this. I personally prefer a specific type for
> interacting with the "outside" world (user_download_t or so) and have
> the apps be able to manage that type rather than user_home_t. But
> that does make it more difficult to explain to users (not really
> userfriendly).
> 
> Thanks for the feedback (also on the other RFC mail)!
> 
> Wkr, Sven Vermeulen _______________________________________________ 
> refpolicy mailing list refpolicy at oss.tresys.com 
> http://oss.tresys.com/mailman/listinfo/refpolicy

Can skype work fine without this ability?  I would think you could add a
boolean and for most people who only do Video or phone calls would not
need the ability to read/write user_home_t.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk45U3QACgkQrlYvE4MpobMbjACeO3zyW/RffRO13e2EjiZ7LaIL
234AoNAjmoQ8gFTgJpx4jN6fzytmSbGs
=1T/u
-----END PGP SIGNATURE-----