Bug 457054 - SELinux is preventing packagekitd (system_dbusd_t) "write" to ./PackageKit (var_lib_t).
SELinux is preventing packagekitd (system_dbusd_t) "write" to ./PackageKit (v...
Status: CLOSED DUPLICATE of bug 457051
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-29 09:49 EDT by Charlie Brady
Modified: 2008-07-29 14:45 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-29 14:45:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Charlie Brady 2008-07-29 09:49:12 EDT
[charlieb@localhost ~]$ sealert -l 38acf215-623e-4c93-941b-edb027b72340

Summary:

SELinux is preventing packagekitd (system_dbusd_t) "write" to ./PackageKit
(var_lib_t).

Detailed Description:

[SELinux is in permissive mode, the operation would have been denied but was
permitted due to permissive mode.]

SELinux is preventing packagekitd (system_dbusd_t) "write" to ./PackageKit
(var_lib_t). The SELinux type var_lib_t, is a generic type for all files in the
directory and very few processes (SELinux Domains) are allowed to write to this
SELinux type. This type of denial usual indicates a mislabeled file. By default
a file created in a directory has the gets the context of the parent directory,
but SELinux policy has rules about the creation of directories, that say if a
process running in one SELinux Domain (D1) creates a file in a directory with a
particular SELinux File Context (F1) the file gets a different File Context
(F2). The policy usually allows the SELinux Domain (D1) the ability to write,
unlink, and append on (F2). But if for some reason a file (./PackageKit) was
created with the wrong context, this domain will be denied. The usual solution
to this problem is to reset the file context on the target file, restorecon -v
'./PackageKit'. If the file context does not change from var_lib_t, then this is
probably a bug in policy. Please file a bug report
(http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against the selinux-policy
package. If it does change, you can try your application again to see if it
works. The file context could have been mislabeled by editing the file or moving
the file from a different directory, if the file keeps getting mislabeled, check
the init scripts to see if they are doing something to mislabel the file.

Allowing Access:

You can attempt to fix file context by executing restorecon -v './PackageKit'

Fix Command:

restorecon './PackageKit'

Additional Information:

Source Context                system_u:system_r:system_dbusd_t:s0
Target Context                system_u:object_r:var_lib_t:s0
Target Objects                ./PackageKit [ dir ]
Source                        packagekitd
Source Path                   /usr/sbin/packagekitd
Port                          <Unknown>
Host                          localhost.localdomain
Source RPM Packages           PackageKit-0.1.12-13.20080522.fc9
Target RPM Packages           
Policy RPM                    selinux-policy-3.3.1-79.fc9
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Permissive
Plugin Name                   mislabeled_file
Host Name                     localhost.localdomain
Platform                      Linux localhost.localdomain
                              2.6.25.11-97.fc9.x86_64 #1 SMP Mon Jul 21 01:09:10
                              EDT 2008 x86_64 x86_64
Alert Count                   185
First Seen                    Sat Apr 26 20:57:36 2008
Last Seen                     Tue Jul 29 09:15:20 2008
Local ID                      38acf215-623e-4c93-941b-edb027b72340
Line Numbers                  

Raw Audit Messages            

host=localhost.localdomain type=AVC msg=audit(1217337320.678:216): avc:  denied
 { write } for  pid=2983 comm="packagekitd" name="PackageKit" dev=dm-0
ino=3638039 scontext=system_u:system_r:system_dbusd_t:s0
tcontext=system_u:object_r:var_lib_t:s0 tclass=dir

host=localhost.localdomain type=AVC msg=audit(1217337320.678:216): avc:  denied
 { add_name } for  pid=2983 comm="packagekitd" name="transactions.db-journal"
scontext=system_u:system_r:system_dbusd_t:s0
tcontext=system_u:object_r:var_lib_t:s0 tclass=dir

host=localhost.localdomain type=AVC msg=audit(1217337320.678:216): avc:  denied
 { create } for  pid=2983 comm="packagekitd" name="transactions.db-journal"
scontext=system_u:system_r:system_dbusd_t:s0
tcontext=system_u:object_r:var_lib_t:s0 tclass=file

host=localhost.localdomain type=AVC msg=audit(1217337320.678:216): avc:  denied
 { read write } for  pid=2983 comm="packagekitd" name="transactions.db-journal"
dev=dm-0 ino=3637328 scontext=system_u:system_r:system_dbusd_t:s0
tcontext=system_u:object_r:var_lib_t:s0 tclass=file

host=localhost.localdomain type=SYSCALL msg=audit(1217337320.678:216):
arch=c000003e syscall=2 success=yes exit=14 a0=1c48440 a1=c2 a2=1a4 a3=0 items=0
ppid=1 pid=2983 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=4294967295 comm="packagekitd" exe="/usr/sbin/packagekitd"
subj=system_u:system_r:system_dbusd_t:s0 key=(null)



[charlieb@localhost ~]$
Comment 1 Charlie Brady 2008-07-29 09:51:19 EDT
[charlieb@localhost ~]$ ls --lcontext /var/lib/PackageKit/transactions.db
-rw-r--r-- 1 system_u:object_r:var_lib_t:s0   root root 191488 2008-07-29 09:15
/var/lib/PackageKit/transactions.db
[charlieb@localhost ~]$ ls --lcontext /var/lib/PackageKit
total 196
-rw-r--r-- 1 system_u:object_r:var_lib_t:s0   root root 191488 2008-07-29 09:15
transactions.db
[charlieb@localhost ~]$ 

If nothing other than packagekitd needs to write to transactions.db (and
transactions.db-journal, and /var/lib/PackageKit), couldn't a specific context
be used, rather than val_lib_t?
Comment 2 Daniel Walsh 2008-07-29 14:45:38 EDT

*** This bug has been marked as a duplicate of 457051 ***

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