Bug 1302736 - SELinux is preventing /bin/chown from 'setattr' accesses on the directory data.
SELinux is preventing /bin/chown from 'setattr' accesses on the directory data.
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2016-01-28 08:51 EST by Raman Gupta
Modified: 2016-02-01 02:37 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-01-30 13:12:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Raman Gupta 2016-01-28 08:51:00 EST
Description of problem:
Something docker related I think. Was using my IDE (Jetbrains IntelliJ IDEA and configuring a docker run config. Don't know how that would trigger this though.
SELinux is preventing /bin/chown from 'setattr' accesses on the directory data.

*****  Plugin catchall_labels (83.8 confidence) suggests   *******************

If you want to allow chown to have setattr access on the data directory
Then you need to change the label on data
# semanage fcontext -a -t FILE_TYPE 'data'
where FILE_TYPE is one of the following: cgroup_t, nfs_t, svirt_home_t, svirt_sandbox_file_t. 
Then execute: 
restorecon -v 'data'

*****  Plugin catchall (17.1 confidence) suggests   **************************

If you believe that chown should be allowed setattr access on the data directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
allow this access for now by executing:
# grep chown /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:svirt_lxc_net_t:s0:c655,c714
Target Context                system_u:object_r:usr_t:s0
Target Objects                data [ dir ]
Source                        chown
Source Path                   /bin/chown
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           coreutils-8.24-5.fc23.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-158.2.fc23.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 4.3.3-303.fc23.x86_64 #1 SMP Tue
                              Jan 19 18:31:55 UTC 2016 x86_64 x86_64
Alert Count                   1
First Seen                    2016-01-28 08:31:50 EST
Last Seen                     2016-01-28 08:31:50 EST
Local ID                      fff724b4-6571-4894-9ff4-7805d38d848b

Raw Audit Messages
type=AVC msg=audit(1453987910.250:1237): avc:  denied  { setattr } for  pid=19443 comm="chown" name="data" dev="dm-0" ino=3803838 scontext=system_u:system_r:svirt_lxc_net_t:s0:c655,c714 tcontext=system_u:object_r:usr_t:s0 tclass=dir permissive=0

type=SYSCALL msg=audit(1453987910.250:1237): arch=x86_64 syscall=fchownat success=no exit=EACCES a0=ffffffffffffff9c a1=1d83de0 a2=66 a3=6a items=0 ppid=19412 pid=19443 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=chown exe=/bin/chown subj=system_u:system_r:svirt_lxc_net_t:s0:c655,c714 key=(null)

Hash: chown,svirt_lxc_net_t,usr_t,dir,setattr

Version-Release number of selected component:

Additional info:
reporter:       libreport-2.6.3
hashmarkername: setroubleshoot
kernel:         4.3.3-303.fc23.x86_64
type:           libreport
Comment 1 Daniel Walsh 2016-01-28 10:36:20 EST
Looks like you are volume mounting /usr content into a container and then trying to chown it, this would neo be allowed.

Where is the data directory?  If you volume mount using :Z
Comment 2 Raman Gupta 2016-01-30 13:12:35 EST
I think I see what happened: the security context of the postgres data directory used by https://github.com/sameersbn/docker-postgresql was not set.

My dev team mapped the postgres data files on the host to a directory in /opt rather than /srv (which explains the usr_t context).

As a side note, why does the output only provide the target basename? I would have immediately identified the issue if it provided the absolute path.

Thanks for replying.

Comment 3 Daniel Walsh 2016-01-31 22:16:57 EST
Full path auditing is turned off by default, since there is some performance hit if you turn it on.  You can enable it by turning on auditing. Although most likely you would never notice.

echo "-w /etc/shadow" >> /etc/audit/rules.d/audit.rules 
systemctl start auditd.service

Will turn it on on your system.
Comment 4 Raman Gupta 2016-02-01 02:37:02 EST

Note You need to log in before you can comment on or make changes to this bug.