Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
I set
DumpLocation = /tmp/abrt
and let abrt to create the dir. It got following context:
drwxr-xr-x. abrt abrt unconfined_u:object_r:abrt_tmp_t:s0 /tmp/abrt
When I crashed app and waited for being processed, I got AVC (comment #0) and following in /var/log/messages:
abrtd: Can't access '/tmp/abrt/ccpp-2011-09-20-12:24:39-27545': Permission denied
abrtd: Corrupted or bad dump /tmp/abrt/ccpp-2011-09-20-12:24:39-27545 (res:2), deleting
abrtd: Can't access '/tmp/abrt/ccpp-2011-09-20-12:24:39-27545': Permission denied
setroubleshoot: SELinux is preventing /usr/sbin/abrtd from create access on the lnk_file .lock. For complete SELinux messages. run sealert -l 9fc886dd-810b-4b02-a7e2-35869a9604a9
setroubleshoot: SELinux is preventing /usr/sbin/abrtd from create access on the lnk_file .lock. For complete SELinux messages. run sealert -l 9fc886dd-810b-4b02-a7e2-35869a9604a9
Well, this is not the default location and in this case when you change the default location, you need to allow it using a local policy.
I could add this to the default policy but I don't like idea to have it in the /tmp dir.
(In reply to comment #3)
> Well, this is not the default location and in this case when you change the
> default location, you need to allow it using a local policy.
>
> I could add this to the default policy but I don't like idea to have it in the
> /tmp dir.
- Sure, it was caused by lack of documentation, we need to warn users, that this will happen if they change the defaults and they have to take care about it themselves...
Miroslav lets add
manage_lnk_files_pattern(abrt_t, abrt_tmp_t, abrt_tmp_t)
If we allow the creation of the file and directory not much reason to prevent the link.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
http://rhn.redhat.com/errata/RHBA-2011-1511.html
abrt version: 2.0.5 executable: /usr/bin/python hashmarkername: setroubleshoot kernel: 2.6.32-198.el6.x86_64 reason: SELinux is preventing /usr/sbin/abrtd from 'create' accesses on the lnk_file .lock. time: Tue Sep 20 12:33:22 2011 description: :SELinux is preventing /usr/sbin/abrtd from 'create' accesses on the lnk_file .lock. : :***** Plugin catchall (100. confidence) suggests *************************** : :If you believe that abrtd should be allowed create access on the .lock lnk_file by default. :Then you should report this as a bug. :You can generate a local policy module to allow this access. :Do :allow this access for now by executing: :# grep abrtd /var/log/audit/audit.log | audit2allow -M mypol :# semodule -i mypol.pp : :Additional Information: :Source Context unconfined_u:system_r:abrt_t:s0-s0:c0.c1023 :Target Context unconfined_u:object_r:abrt_tmp_t:s0 :Target Objects .lock [ lnk_file ] :Source abrtd :Source Path /usr/sbin/abrtd :Port <Unknown> :Host (removed) :Source RPM Packages abrt-2.0.4-10.el6 :Target RPM Packages :Policy RPM selinux-policy-3.7.19-110.el6 :Selinux Enabled True :Policy Type targeted :Enforcing Mode Enforcing :Host Name (removed) :Platform Linux (removed) : 2.6.32-198.el6.x86_64 #1 SMP Thu Sep 15 23:40:38 : EDT 2011 x86_64 x86_64 :Alert Count 2 :First Seen Tue 20 Sep 2011 12:25:15 PM CEST :Last Seen Tue 20 Sep 2011 12:25:15 PM CEST :Local ID 9fc886dd-810b-4b02-a7e2-35869a9604a9 : :Raw Audit Messages :type=AVC msg=audit(1316514315.268:2195): avc: denied { create } for pid=27543 comm="abrtd" name=".lock" scontext=unconfined_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:abrt_tmp_t:s0 tclass=lnk_file : : :type=SYSCALL msg=audit(1316514315.268:2195): arch=x86_64 syscall=symlink success=no exit=EACCES a0=7fff2365a210 a1=7fff2365a1b0 a2=353435 a3=fffffffffffffff0 items=0 ppid=1 pid=27543 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm=abrtd exe=/usr/sbin/abrtd subj=unconfined_u:system_r:abrt_t:s0-s0:c0.c1023 key=(null) : :Hash: abrtd,abrt_t,abrt_tmp_t,lnk_file,create : :audit2allow : :#============= abrt_t ============== :allow abrt_t abrt_tmp_t:lnk_file create; : :audit2allow -R : :#============= abrt_t ============== :allow abrt_t abrt_tmp_t:lnk_file create; :