Fixed in selinux-policy-3.7.19-93.el6_1.4.

May I kindly ask to retest this bug on RHEL6.1 with selinux-policy-3.7.19-93.el6_1.4? Thank you in advance.

(In reply to comment #6)
> May I kindly ask to retest this bug on RHEL6.1 with
> selinux-policy-3.7.19-93.el6_1.4? Thank you in advance.

This package version had some problems that were addressed in selinux-policy-3.7.19-93.el6_1.5 (see bug 727039 for details).

I tested for this bug using the new selinux-policy-3.7.19-93.el6_1.5 package, but I still encounter a problem.  I still see the following AVC:

type=AVC msg=audit(1312821744.482:25274): avc:  denied  { write } for  pid=7132 comm="ns-slapd" path="/tmp/startup.7125" dev=dm-0 ino=234193 scontext=unconfined_u:system_r:dirsrv_t:s0 tcontext=unconfined_u:object_r:dirsrvadmin_tmp_t:s0 tclass=file
type=SYSCALL msg=audit(1312821744.482:25274): arch=40000003 syscall=11 success=yes exit=0 a0=8723600 a1=87239f0 a2=8723418 a3=87239f0 items=0 ppid=7129 pid=7132 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="ns-slapd" exe="/usr/sbin/ns-slapd" subj=unconfined_u:system_r:dirsrv_t:s0 key=(null)

The startup output is redirected to a tmp file by the CGI, but ns-slapd (dirsrv_t) is blocked from writing to that file since it is labelled as dirsrvadmin_tmp_t.  We can just allow dirsrv_t to write to dirsrvadmin_tmp_t files to resolve this.

Are you getting only this AVC msg? Could you try to swith to permissive mode globally

setenforce 0

and make sure that only this avc remaining.

(In reply to comment #8)
> Are you getting only this AVC msg? Could you try to swith to permissive mode
> globally
> 
> setenforce 0
> 
> and make sure that only this avc remaining.

Yes, this was in permissive mode.

Nathan,
could you test it with 

https://brewweb.devel.redhat.com/buildinfo?buildID=175311

before I update errata. Thanks.

(In reply to comment #10)
> Nathan,
> could you test it with 
> 
> https://brewweb.devel.redhat.com/buildinfo?buildID=175311
> 
> before I update errata. Thanks.

Looks good.  I get no AVC messages now when doing a DS instance restart via Console.  Thanks for the quick turn-around on this new package!

Unfortunately the bug is not fixed.
I think Nathat did the test in permissive and therefore missed dontaudited denials.
I tried to reproduce the test scenario from Nathan (directory server reboot fails in enforcing) with
selinux-policy-3.7.19-93.el6_1.6.noarch
redhat-ds-9.0.0-1.el6.x86_64
389-ds-console-1.2.6-1.el6.noarch
389-console-1.1.7-1.el6.noarch
389-adminutil-1.1.14-1.el6.x86_64
389-ds-base-1.2.8.2-1.el6_1.8.x86_64
389-admin-console-1.1.8-1.el6.noarch
389-ds-console-doc-1.2.6-1.el6.noarch
389-ds-base-libs-1.2.8.2-1.el6_1.8.x86_64
389-admin-1.1.21-1.el6.x86_64
389-admin-console-doc-1.1.8-1.el6.noarch

creating a ds produce (dontaudited) AVCs:

type=AVC msg=audit(1312970664.912:101314): avc:  denied  { read write } for  pid=7038 comm="ns-slapd" path="socket:[66837]" dev=sockfs ino=66837 scontext=unconfined_u:system_r:dirsrv_t:s0 tcontext=unconfined_u:system_r:httpd_t:s0 tclass=unix_stream_socket
type=AVC msg=audit(1312970664.912:101314): avc:  denied  { read write } for  pid=7038 comm="ns-slapd" path="socket:[66834]" dev=sockfs ino=66834 scontext=unconfined_u:system_r:dirsrv_t:s0 tcontext=unconfined_u:system_r:httpd_t:s0 tclass=unix_stream_socket

restarting a ds produce (dontaudited) AVCs (restart fails):

type=AVC msg=audit(1312970819.720:101326): avc:  denied  { read write } for  pid=7437 comm="ds_restart" path="socket:[71804]" dev=sockfs ino=71804 scontext=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0 tcontext=unconfined_u:system_r:httpd_t:s0 tclass=unix_stream_socket
type=AVC msg=audit(1312970819.720:101326): avc:  denied  { read write } for  pid=7437 comm="ds_restart" path="socket:[71804]" dev=sockfs ino=71804 scontext=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0 tcontext=unconfined_u:system_r:httpd_t:s0 tclass=unix_stream_socket
type=AVC msg=audit(1312970819.720:101326): avc:  denied  { read write } for  pid=7437 comm="ds_restart" path="socket:[66834]" dev=sockfs ino=66834 scontext=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0 tcontext=unconfined_u:system_r:httpd_t:s0 tclass=unix_stream_socket
type=AVC msg=audit(1312970821.738:101327): avc:  denied  { write } for  pid=7439 comm="sh" name="/" dev=dm-0 ino=2 scontext=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir


I have created a module using audit2allow -M and load it.
After that, domain restart produced another AVC (admin GUI freezed) so I have switched to permissive and restarted directory server which resulted in:

type=AVC msg=audit(1312971115.445:101341): avc:  denied  { add_name } for  pid=8031 comm="sh" name="startup.8028" scontext=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir
type=AVC msg=audit(1312971561.610:101349): avc:  denied  { create } for  pid=8815 comm="sh" name="startup.8812" scontext=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0 tcontext=unconfined_u:object_r:root_t:s0 tclass=file
type=AVC msg=audit(1312971903.080:101370): avc:  denied  { write open } for  pid=9684 comm="sh" name="startup.9681" dev=dm-0 ino=12 scontext=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0 tcontext=unconfined_u:object_r:root_t:s0 tclass=file
type=AVC msg=audit(1312971904.195:101372): avc:  denied  { read } for  pid=9681 comm="ds_restart" name="startup.9681" dev=dm-0 ino=12 scontext=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0 tcontext=unconfined_u:object_r:root_t:s0 tclass=file
type=AVC msg=audit(1312971904.195:101373): avc:  denied  { getattr } for  pid=9681 comm="ds_restart" path="/startup.9681" dev=dm-0 ino=12 scontext=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0 tcontext=unconfined_u:object_r:root_t:s0 tclass=file
type=AVC msg=audit(1312971904.195:101374): avc:  denied  { remove_name } for  pid=9681 comm="ds_restart" name="startup.9681" dev=dm-0 ino=12 scontext=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir
type=AVC msg=audit(1312971904.195:101374): avc:  denied  { unlink } for  pid=9681 comm="ds_restart" name="startup.9681" dev=dm-0 ino=12 scontext=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0 tcontext=unconfined_u:object_r:root_t:s0 tclass=file

With all those denials allowed I can successfuly create a directory server instance, restart it and remove (in enforcing, no AVC).

For some reason the "Start directory server" action didn't work (window freeze, action in progress, never finished with message like "instance started") but that wasn't selinux related issue (same thing in permissive mode)

> type=AVC msg=audit(1312970664.912:101314): avc:  denied  { read write } for 
> pid=7038 comm="ns-slapd" path="socket:[66837]" dev=sockfs ino=66837
> scontext=unconfined_u:system_r:dirsrv_t:s0
> tcontext=unconfined_u:system_r:httpd_t:s0 tclass=unix_stream_socket
> type=AVC msg=audit(1312970664.912:101314): avc:  denied  { read write } for 
> pid=7038 comm="ns-slapd" path="socket:[66834]" dev=sockfs ino=66834
> scontext=unconfined_u:system_r:dirsrv_t:s0
> tcontext=unconfined_u:system_r:httpd_t:s0 tclass=unix_stream_socket

make sense to fix and I need to add them.

Nathan,
AVC messages related to "root_t:s0" are the same which we discussed in 

https://bugzilla.redhat.com/show_bug.cgi?id=710357#c11

and you fixed them in

https://bugzilla.redhat.com/show_bug.cgi?id=724808

(In reply to comment #13)
> > type=AVC msg=audit(1312970664.912:101314): avc:  denied  { read write } for 
> > pid=7038 comm="ns-slapd" path="socket:[66837]" dev=sockfs ino=66837
> > scontext=unconfined_u:system_r:dirsrv_t:s0
> > tcontext=unconfined_u:system_r:httpd_t:s0 tclass=unix_stream_socket
> > type=AVC msg=audit(1312970664.912:101314): avc:  denied  { read write } for 
> > pid=7038 comm="ns-slapd" path="socket:[66834]" dev=sockfs ino=66834
> > scontext=unconfined_u:system_r:dirsrv_t:s0
> > tcontext=unconfined_u:system_r:httpd_t:s0 tclass=unix_stream_socket
> 
> make sense to fix and I need to add them.

I thought these

type=AVC msg=audit(1312970819.720:101326): avc:  denied  { read write } for 
pid=7437 comm="ds_restart" path="socket:[71804]" dev=sockfs ino=71804
scontext=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0
tcontext=unconfined_u:system_r:httpd_t:s0 tclass=unix_stream_socket
type=AVC msg=audit(1312970819.720:101326): avc:  denied  { read write } for 
pid=7437 comm="ds_restart" path="socket:[71804]" dev=sockfs ino=71804
scontext=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0

(In reply to comment #14)
> Nathan,
> AVC messages related to "root_t:s0" are the same which we discussed in 
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=710357#c11
> 
> and you fixed them in
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=724808

That is correct.  These were a bug in the 389-admin package that was recently fixed.  We do not have a build with this fix yet, though we expect one in the next day or two.  We can ignore the root_t issues as far as the testing for this bug goes.

(In reply to comment #12)
> For some reason the "Start directory server" action didn't work (window freeze,
> action in progress, never finished with message like "instance started") but
> that wasn't selinux related issue (same thing in permissive mode)

It has a timeout of 600 seconds to read the startup output, so it will appear to freeze until that timeout expires.  At that point, an error dialog will pop up.  This is due to the root_t issues mentioned above.

Great.

> (In reply to comment #12)
> > For some reason the "Start directory server" action didn't work (window freeze,
> > action in progress, never finished with message like "instance started") but
> > that wasn't selinux related issue (same thing in permissive mode)
> 
> It has a timeout of 600 seconds to read the startup output, so it will appear
> to freeze until that timeout expires.  At that point, an error dialog will pop
> up.  This is due to the root_t issues mentioned above.

Do you mean that root_t issue is not only selinux related? Because I have created a module to allow all root_t issues and also tried it in permissive mode. The start up didn't work anyway. If there are some non-selinux issues too, it is OK then. But it is definitely selinux fault.

> We do not have a build with this fix yet, though we expect one in the
> next day or two.  We can ignore the root_t issues as far as the testing for
> this bug goes.
I would prefer to retest it on a build with the root_t fix. Just to be sure we do not realease the update with unresolved issues.

Tested with selinux-policy-3.7.19-93.el6_1.7 on i386 platform.

I have successfuly performed following actions:
-service dirsrv-admin restart
-service dirsrv restart

Using redhat-idm-console"
- create directory server instance
- stop/start/restart directory server instance
- remove directory server instance

No AVC nor crashes/freeze.

Anyway I would like to restest it with the new 389 build on x86_64 before switching this bug to VERIFIED.

(In reply to comment #18)
> Do you mean that root_t issue is not only selinux related? Because I have
> created a module to allow all root_t issues and also tried it in permissive
> mode. The start up didn't work anyway. If there are some non-selinux issues
> too, it is OK then. But it is definitely selinux fault.

What I mean is that 389-ds-base should not be writing to '/' (root_t) in the first place.  The policy is correct, as dirsrv_t should not be allowed to write to a root_t area.  There was a path creation bug in the 389-admin package that caused us to write to '/' instead of '/tmp', which is what you are seeing on your x86_64 system.

> I would prefer to retest it on a build with the root_t fix. Just to be sure we
> do not realease the update with unresolved issues.

I will let you know as soon as the new 389-admin build is ready.

(In reply to comment #19)
> Anyway I would like to restest it with the new 389 build on x86_64 before
> switching this bug to VERIFIED.

The fix is available in 389-admin-1.1.22-1.el6, which can be downloaded from the following location:

  https://brewweb.devel.redhat.com/buildinfo?buildID=175618

Just as an FYI, there may be a newer build available by the time you read this update, as we're working on a 389-admin-1.1.23-1.el6 for a different fix.  Just use the latest that you find available.  These should go into the DS testing repo tonight, but you can grab them from brew if you don't see them in the repo.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-1193.html