Re: [atomic-devel] SELinux labelling when running Pulp in containers

[Daniel J Walsh <dwalsh redhat com>]

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.