Bug 798036 - selinux policy prevents rpm from creating directory in /var/lib/
Summary: selinux policy prevents rpm from creating directory in /var/lib/
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 16
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 828606 853456 863832
TreeView+ depends on / blocked
 
Reported: 2012-02-27 21:31 UTC by Chris Meek
Modified: 2013-02-27 00:09 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 828606 853456 (view as bug list)
Environment:
Last Closed: 2013-02-14 02:01:34 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
useradd strace output (47.08 KB, text/plain)
2012-02-27 21:31 UTC, Chris Meek
no flags Details

Description Chris Meek 2012-02-27 21:31:39 UTC
Created attachment 566148 [details]
useradd strace output

Description of problem:
When trying to install systemtap-server-1.7-2.fc16.x86_64 on 
Fedora 16, selinux prevents the rpm from creating 
/var/lib/stap-server/ as the home directory when running
useradd. 


Version-Release number of selected component (if applicable):
kernel-3.2.5-3.fc16.x86_64


How reproducible:
Every time.


Steps to Reproduce:
1. # yum install systemtap-server
2. # service stap-server start
  

Actual results:
When running the yum install above, this output is seen:

warning: user stap-server does not exist - using root
runuser: user stap-server does not exist
Could not open certificate file ~stap-server/.systemtap/ssl/server/stap.cert for reading
No such file or directory
Unable to authorize certificate
Could not open certificate file ~stap-server/.systemtap/ssl/server/stap.cert for reading
No such file or directory
Unable to authorize certificate


Expected results:
Should create the new stap-server user without an issue.


Additional info:
The section in the systemtap.spec file that causes the problem is:

%pre server
getent group stap-server >/dev/null || groupadd -g 155 -r stap-server || groupadd -r stap-server
getent passwd stap-server >/dev/null || \
useradd -c "Systemtap Compile Server" -u 155 -g stap-server -d %{_localstatedir}/lib/stap-server -m -r -s /sbin/nologin stap-server     || \
useradd -c "Systemtap Compile Server" -g stap-server -d %{_localstatedir}/lib/stap-server -m -r -s /sbin/nologin stap-server
test -e ~stap-server && chmod 755 ~stap-server
exit 0

When run by hand with strace with the following command, the output is attached:

# strace -f useradd -c "Systemtap Compile Server" -u 155 -g stap-server -d /var/lib/stap-server -m -r -s /sbin/nologin stap-server

Comment 1 Miroslav Grepl 2012-02-28 18:44:14 UTC
What AVC msgs are you getting?

$ ausearch -m avc -ts today

Comment 2 Chris Meek 2012-02-29 14:36:59 UTC
It appears that I'm not getting any AVC messages from this issue. The last one I got was on Dec 21, 2011.

Comment 3 Daniel Walsh 2012-02-29 19:11:21 UTC
Are you still seeing the useradd blow up?

Comment 4 Chris Meek 2012-02-29 20:10:43 UTC
I temporarily put selinux in permissive mode (# setenforce 0) and that let it run useradd properly, but in enforcing mode it still causes the problem.

Comment 5 Miroslav Grepl 2012-03-01 08:06:02 UTC
Ok, could you try

$ ts = `date +%TS`
$ setenforce 1
$ setenforce 0

re-test and

$ ausearch -m avc -ts $ts

Comment 6 Chris Meek 2012-03-01 14:56:17 UTC
hmm I did every step listed above, and still the AVC messages are empty...

Comment 7 Daniel Walsh 2012-03-01 21:07:07 UTC
Right the problem is something is being dontaudited 


semodule -DB
re-test
and now you will get lots of AVCs

semodule -B

Will turn them back off.

Comment 8 Chris Meek 2012-03-02 15:13:19 UTC
Still no luck... I tried setting semodule -DB and there are still no AVC messages.

Comment 9 Miroslav Grepl 2012-03-02 15:27:38 UTC
Is auditd running?

Comment 11 Philip Withnall 2012-07-20 20:07:21 UTC
(In reply to comment #1)
> What AVC msgs are you getting?
> 
> $ ausearch -m avc -ts today

time->Fri Jul 20 21:06:19 2012
type=SYSCALL msg=audit(1342814779.475:4762): arch=c000003e syscall=83 success=no exit=-13 a0=7fff352b48ec a1=0 a2=0 a3=65726373662f7274 items=0 ppid=25098 pid=25101 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=3 comm="useradd" exe="/usr/sbin/useradd" subj=unconfined_u:system_r:useradd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1342814779.475:4762): avc:  denied  { write } for  pid=25101 comm="useradd" name="lib" dev="dm-1" ino=16 scontext=unconfined_u:system_r:useradd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=dir
----
time->Fri Jul 20 21:06:19 2012
type=SYSCALL msg=audit(1342814779.650:4766): arch=c000003e syscall=83 success=no exit=-13 a0=7fff84eb38ec a1=0 a2=0 a3=65726373662f7274 items=0 ppid=25098 pid=25102 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=3 comm="useradd" exe="/usr/sbin/useradd" subj=unconfined_u:system_r:useradd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1342814779.650:4766): avc:  denied  { write } for  pid=25102 comm="useradd" name="lib" dev="dm-1" ino=16 scontext=unconfined_u:system_r:useradd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=dir

Comment 12 Daniel Walsh 2012-07-20 21:26:16 UTC
Is a users homedir being added to the /var/lib directory

Comment 13 Frank Ch. Eigler 2012-07-20 22:22:55 UTC
Daniel, yes, a server userid's home directory is put there as a storage spot for various persistent data.

Comment 14 Daniel Walsh 2012-07-23 15:44:23 UTC
Any in particular, Miroslav I guess we should just allow this in general, but if we have specific cases where the homedir needs to be labeled differently. we should add transition rules.

Comment 15 Miroslav Grepl 2012-07-24 11:02:54 UTC
Also we added a new stapserver policy to rawhide to fix this issue. But the policy still need more testing.

Comment 16 Fedora End Of Life 2013-02-14 02:01:44 UTC
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


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