Bug 191513 - avc: denied { write } for pid=19275 comm="useradd" name="[906158]" dev=pipefs ino=906158 scontext=user_u:system_r:useradd_t:s0 tcontext=user_u:system_r:unconfined_t:s0 tclass=fifo_file
Summary: avc: denied { write } for pid=19275 comm="useradd" name="[906158]" dev=pip...
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted   
(Show other bugs)
Version: 5
Hardware: All Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2006-05-12 16:50 UTC by Orion Poplawski
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-02-14 15:17:25 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Orion Poplawski 2006-05-12 16:50:15 UTC
Description of problem:

These were generated when the cron.daily yum update upgraded ntp, which runs:

preinstall scriptlet (using /bin/sh):
/usr/sbin/groupadd -g 38 ntp  2> /dev/null || :
/usr/sbin/useradd -u 38 -g 38 -s /sbin/nologin -M -r -d /etc/ntp ntp 2>/dev/null
|| :

May 12 04:50:07 cynosure kernel: audit(1147431007.092:29): avc:  denied  { write
} for  pid=19274 comm="groupadd" name="[906158]" dev=pipefs ino=906158
scontext=user_u:system_r:groupadd_t:s0 tcontext=user_u:system_r:unconfined_t:s0
May 12 04:50:07 cynosure kernel: audit(1147431007.320:30): avc:  denied  { write
} for  pid=19275 comm="useradd" name="[906158]" dev=pipefs ino=906158
scontext=user_u:system_r:useradd_t:s0 tcontext=user_u:system_r:unconfined_t:s0

Version-Release number of selected component (if applicable):

Additional info:

We're running NIS:

passwd:     files nis
group:      files nis

I don't seem to get the message if I run the groupadd command from the shell.

Comment 1 Daniel Walsh 2006-06-16 01:36:04 UTC
The weird thing here is that cron ran these rpms in unconfined_t instead of rpm_t?

How is your yum executable labeled?


Comment 2 Orion Poplawski 2006-07-11 21:34:12 UTC
Just tested this again, and I still get the message.  yum is labeled:

-rwxr-xr-x  root root system_u:object_r:rpm_exec_t     /usr/bin/yum

-rwxr-xr-x  root root system_u:object_r:useradd_exec_t /usr/sbin/useradd
-rwxr-xr-x  root root system_u:object_r:groupadd_exec_t /usr/sbin/groupadd

crond process:

system_u:system_r:crond_t:SystemLow-SystemHigh root 2499 1  0 Jul07 ?  00:00:00

isn't it the pipe that unlabeled, not the process (running useradd_t or groupadd_t)?

Comment 3 Daniel Walsh 2006-10-05 12:39:55 UTC
OK I think I know what the problem is.  

crond is broken and mistakenly running system jobs as user_crond_t.  It is
supposed to run them as system_crond_t, which would work better, or at least
make sense.  The problem is the policy says rpm can talk to that fifo_file but
not stuff in the post install scripts.  These problems are a pain to fix, since
everyone down the line needs to dontaudit the open fifo_file.  In FC6 we have
added yum-updatesd to better handle what you are trying to do, BTW.

Comment 4 Orion Poplawski 2006-11-22 14:36:05 UTC
Any chance of this getting fixed in FC5?  I've been testing out FC6 and haven't
been impressed with yum-updatesd so far.

Comment 5 Daniel Walsh 2006-11-27 15:27:05 UTC
My intention is to update FC5 to FC6 policy.  Problem is I have not been able to
test if this causes other problems, because I have been so busy with FC6 and
RHEL5 stuff.  If you want to test it.  http://people.redhat.com/dwalsh/SELinux/FC5

Comment 6 Orion Poplawski 2007-01-24 16:59:26 UTC
Still see:

Jan 23 04:58:33 coop01 kernel: audit(1169553513.928:7): avc:  denied  { write }
for  pid=28999 comm="groupadd" name="[9657153]" dev=pipefs ino=9657153
scontext=user_u:system_r:groupadd_t:s0 tcontext=user_u:system_r:unconfined_t:s0



Comment 7 Daniel Walsh 2007-02-14 15:17:25 UTC
All of these bugs should be fixed in FC6,  You could attempt to use the FC6
policy on FC5 or upgrade.  Or you could use 

audit2allow -M mypolicy -i /var/log/audit/audit.log 
and build local customized policy

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