From: dac.override@gmail.com (Dominick Grift)
Date: Fri, 27 May 2016 17:13:55 +0200
Subject: [refpolicy] resolv.conf managed by NetworkManager or networkd
In-Reply-To: <9d9714a8-b8e7-2fc3-36f3-0cfd22e56664@tresys.com>
References: <8eb3ec05-9937-d097-1cc7-52de9e459586@debian.org>
	<9d9714a8-b8e7-2fc3-36f3-0cfd22e56664@tresys.com>
Message-ID: <98f8a6af-e937-2dd6-0d89-8a7c5a3df8fe@gmail.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/27/2016 05:11 PM, Christopher J. PeBenito wrote:
> On 5/26/2016 9:49 AM, Laurent Bigonville wrote:
>> Hello,
>> 
>> On systems running NetworkManager or systemd-networkd, the
>> resolv.conf file is managed by that daemon and written in some
>> private directory (/var/run/NetworkManager or
>> /run/systemd/resolve/). A symlink /etc/resolv.conf is then
>> created.
>> 
>> That means that application should be able to read a file that
>> will be labeled as NetworkManager_var_run_t (or some other
>> private type for networkd). One of the idea what to modify the
>> sysnet_read_config() interface but this lead to compilation is
>> due to boolean/optional policy mix.
>> 
>> An idea how to fix that?
> 
>> From doing a little searching, I assume the problem is with
> sysnet_read_config() being in the allow_ypbind conditional?  It
> would put an optional inside a conditional, which isn't allowed by
> the compiler.
> 
> Is a named filetrans impossible to work for this situation, so when
> the two services create it the file it still ends up net_conf_t?
> 

That still wouldnt work since callers of sysnet_read_config would
still need to traverse NetworkManager and systemd-resolved runtime
dirs to get to /run/NetworkManager/resolv.conf and
/run/systemd/systemd-resolved/resolv.conf

Unless you want to make sysnet depend on the networkmanager and
systemd modules

- -- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCAAGBQJXSGQuAAoJECV0jlU3+UdpUfML/0uOm0CXaNyze5Np0yKHwGyM
k1/ELPjJyOmjQz1bgQCUvpC8XOsAskqAXuHM/c2PrW0KkzzPogFzCCXWWAW6AEsE
zR5bUdUg4LyI7LWHKfBY+H7JMUmIal//D9BLaOjNY6P5UWWl5O6kAYvcgFua5SmL
I5Fo0IicFhNjDBbDzIThjBLyPQuxkmiSPLd2pC1XCLfO5FlB3vQKBc9bvLVD1a/N
cfVTmZbe8VI08BsFB0osyz7jCfSucv9ZMt2jqHVfraq31npK/VxkDlUnK0/rzG4n
S/3yX98QFtWjdGnpdflpLgD22ZnfjQLdT9qxLoWxGysyRpVeJq1vWhXqZk3jJnRs
0q2QTfzCNONxLPtlz2cRz0qxHSRbSXQpUsG7YnRiWsSbn6cf9EAWsWccfsoVLCp5
4wIlYGJ9h7SOuiTA5Yrne7kVlEOz2rwt4fdXzoiaxzUhUFxhvNS/K0vH8N4WUvhy
fBU2uYit0pboeVrwA3WG3ohGKBWoutUWtyZdcHdAKw==
=4zvK
-----END PGP SIGNATURE-----