[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [atomic-devel] SELinux labelling when running Pulp in containers
- From: Daniel J Walsh <dwalsh redhat com>
- To: Nick Coghlan <ncoghlan gmail com>, "atomic-devel projectatomic io" <atomic-devel projectatomic io>
- Subject: Re: [atomic-devel] SELinux labelling when running Pulp in containers
- Date: Thu, 3 Sep 2015 07:56:26 -0400
On 09/03/2015 07:51 AM, Daniel J Walsh wrote:
>
> On 09/02/2015 08:14 PM, Nick Coghlan wrote:
>> To help improve the local dev experience for a project I'm working on
>> that uses Pulp, I've been looking at making it easier to get a local
>> dev instance of that up and running in containers.
>>
>> Building on Michael Hrivnak's previous work, I got Pulp fully
>> containerised in
>> https://github.com/ncoghlan/repofunnel/blob/master/_localdev/start_pulp.sh
>> (with a couple of messy hacks to work around the inability to change
>> mount points or the owning user when mounting volumes via
>> --volumes-from).
>>
>> However, I've only managed to get it working under "setenforce 0" -
>> SELinux complains otherwise. After bringing this up internally, I
>> realised I should start a thread here with the relevant setroubleshoot
>> details. (Containerising Pulp for local development serves as a
>> precursor to getting it running on Atomic Host, so this seems like the
>> most appropriate upstream list to provide feedback on the challenges I
>> encountered with it).
>>
>> For reference, the containers involved in running Pulp locally are:
>>
>> * pulp_data - just owns the data volumes
>> * pulp_db - MongoDB container
>> * pulp_qpid - Qpid message broker
>> * pulp_beat - (I don't actually know what this does...)
>> * pulp_resource_manager - (ditto...)
>> * pulp_worker[12] - celery worker nodes (I believe)
>> * pulpapi - web service for main REST API
>> * crane - Docker registry service
>>
>> The first 3 containers have no dependencies, the others all mount
>> volumes from pulp_data, and have network links to pulp_db and
>> pulp_qpid. All the containers also mount "/dev/log:Z" from the host.
>>
>> Running "sudo _localdev/start_pulp.sh" under SELinux, only the
>> database and QPid containers start properly - the later ones which
>> need to link network interfaces to those containers all fail.
>>
>> The setroubleshoot message that seems relevant (both by time and content) is:
>>
>> =============
>> SELinux is preventing nm-dispatcher from read access on the lnk_file
>> log. For complete SELinux messages. run sealert -l
>> 7a75e20f-208a-432a-8b71-008f2c2c94d5
>> =============
>>
>> And the additional information from sealert:
>> =============
>> Source Context system_u:system_r:NetworkManager_t:s0
>> Target Context system_u:object_r:svirt_sandbox_file_t:s0:c88,c647
>> Target Objects log [ lnk_file ]
>> Source nm-dispatcher
>> Source Path nm-dispatcher
>> Port <Unknown>
>> Host thechalk
>> Source RPM Packages
>> Target RPM Packages
>> Policy RPM selinux-policy-3.13.1-128.12.fc22.noarch
>> Selinux Enabled True
>> Policy Type targeted
>> Enforcing Mode Enforcing
>>
>> Raw Audit Messages
>> type=AVC msg=audit(1441238305.121:883): avc: denied { read } for
>> pid=5928 comm="nm-dispatcher" name="log" dev="devtmpfs"
>> ino=10641 scontext=system_u:system_r:NetworkManager_t:s0
>> tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c88,c647 tclas
>> s=lnk_file permissive=0
>>
>> Hash: nm-dispatcher,NetworkManager_t,svirt_sandbox_file_t,lnk_file,read
>> =============
>>
>> Regards,
>> Nick.
>>
>> P.S. There's also a secondary failure that appears to stem from
>> failing to record the above alert properly: "could not write
>> /var/lib/setroubleshoot/setroubleshoot_database.xml: [Errno 13]
>> Permission denied:
>> '/var/lib/setroubleshoot/setroubleshoot_database.xml'"
>>
> Where is log located. Looks like you have a symbolic link used by a
> container called log that NetworkManager is trying to read.
>
Remove the :Z from this line. You don't want to relabel /dev/log on the
host.
MOUNTS="--volumes-from pulp_data -v /dev/log:/dev/log:Z"
You should only be relabeling content specific to the container.
restorecon -F /dev/log
on the host should fix this label.
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]