Bug 619654 - SELinux is preventing /usr/bin/python "write" access on /var/spool/up2date/loginAuth.pkl.
Summary: SELinux is preventing /usr/bin/python "write" access on /var/spool/up2da...
Status: CLOSED DUPLICATE of bug 619653
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: rhn-client-tools
Version: 6.0
Hardware: x86_64
OS: Linux
Target Milestone: rc
: ---
Assignee: Milan Zázrivec
QA Contact: Red Hat Satellite QA List
Whiteboard: setroubleshoot_trace_hash:153bf3545e4...
Keywords: RHELNAK
Depends On:
TreeView+ depends on / blocked
Reported: 2010-07-30 04:36 UTC by Ladar Levison
Modified: 2010-08-09 17:28 UTC (History)
12 users (show)

Clone Of:
Last Closed: 2010-08-09 17:28:59 UTC

Attachments (Terms of Use)

Description Ladar Levison 2010-07-30 04:36:54 UTC

SELinux is preventing /usr/bin/python "write" access on

Detailed Description:

SELinux denied access requested by yum. It is not expected that this access is
required by yum and this access may signal an intrusion attempt. It is also
possible that the specific version or configuration of the application is
causing it to require additional access.

Allowing Access:

You can generate a local policy module to allow this access - see FAQ
(http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug

Additional Information:

Source Context                system_u:system_r:abrt_t:s0-s0:c0.c1023
Target Context                unconfined_u:object_r:var_spool_t:s0
Target Objects                /var/spool/up2date/loginAuth.pkl [ file ]
Source                        yum
Source Path                   /usr/bin/python
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           python-2.6.2-11.el6
Target RPM Packages           rhn-client-tools-1.0.0-24.el6
Policy RPM                    selinux-policy-3.7.19-29.el6
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   catchall
Host Name                     (removed)
Platform                      Linux (removed) 2.6.32-44.2.el6.x86_64 #1
                              SMP Wed Jul 21 12:48:32 EDT 2010 x86_64 x86_64
Alert Count                   2
First Seen                    Thu 29 Jul 2010 11:33:52 PM CDT
Last Seen                     Thu 29 Jul 2010 11:33:53 PM CDT
Local ID                      7fa8491d-74ef-482f-9c17-382b875d6459
Line Numbers                  

Raw Audit Messages            

node=(removed) type=AVC msg=audit(1280464433.57:27): avc:  denied  { write } for  pid=3163 comm="yum" name="loginAuth.pkl" dev=sda3 ino=3670112 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_spool_t:s0 tclass=file

node=(removed) type=SYSCALL msg=audit(1280464433.57:27): arch=c000003e syscall=2 success=no exit=-13 a0=2c1b220 a1=241 a2=1b6 a3=0 items=0 ppid=3162 pid=3163 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="yum" exe="/usr/bin/python" subj=system_u:system_r:abrt_t:s0-s0:c0.c1023 key=(null)

Hash String generated from  catchall,yum,abrt_t,var_spool_t,file,write
audit2allow suggests:

#============= abrt_t ==============
allow abrt_t var_spool_t:file write;

Comment 2 RHEL Product and Program Management 2010-07-30 05:07:44 UTC
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

Comment 3 Daniel Walsh 2010-07-30 18:10:15 UTC
What is  /var/spool/up2date/loginAuth.pkl?

Is this a log file where you have all apps being updated having their stdout pointing at it?  Or is this a leaked file descriptor?

Comment 4 Milan Zázrivec 2010-07-30 19:08:31 UTC
/var/spool/up2date/loginAuth.pkl is a pickle file which caches authentication
information for connecting to RHN, RHN Satellite or Spacewalk.

The file is being used by every process (via rhnlib or rhn-client-tools
libraries) trying to authenticate with RHN, such as rhn_check or in this
case yum (which has yum-rhn-plugin enabled).

Is there something that we (as in the owners of the rhn-client-tools / 
yum-rhn-plugin code) can do to resolve the problem?

Comment 5 Daniel Walsh 2010-08-03 19:30:09 UTC
Open it for append instead of write.

Comment 6 Milan Zázrivec 2010-08-05 09:46:16 UTC
This essentially is the same problem as bug #619653

Comment 7 Daniel Walsh 2010-08-05 13:39:37 UTC
Yes and no.  We can set the labeling correct, but the tool should not be opening a log file as write and then passing the open descriptor to lots of other commands.  If the confined commands have write, they can truncate the log file.  If they have append they can only add data to the end of the log file.

Comment 8 Denise Dumas 2010-08-06 14:43:01 UTC
So should this be assigned to rhn-client-tools?

Comment 9 Milan Zázrivec 2010-08-09 11:00:20 UTC
(In reply to comment #8)
> So should this be assigned to rhn-client-tools?    


There's nothing to fix in the land of rhn-client-tools really.

/var/spool/up2date/loginAuth.pkl is not a log file and cannot be
opened in append mode. The file is either being opened for read
when yum (or yum-rhn-plugin) needs to get the authentication information
or in write mode when the file needs to be truncated and its
content replaced with new authentication info (for example when
the old authentication info expires). So it's sort of a cookie mechanism.

This really is a matter of selinux policy (or labeling) and looking at
the solution for bug #619653 I see /var/spool/up2date/loginAuth.pkl
already got rpm_var_cache_t context which will allow write for abrt_t
(among others).

In another words, solution for bug #619653 also effectively solves
problem of this bug and as such I suggest to close this bug as
a duplicate of #619653 (unless somebody objects).

Comment 10 Denise Dumas 2010-08-09 17:28:59 UTC
Closing based on ^^^

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

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