Bug 728360

-8174 is SEC_ERROR_BAD_DATABASE
The init script runs the broker as the user "qpidd". I am guessing that user does not have access to the directory /tmp/matahari/cert_db/ since running it as root works.

It is still an issue when the database has 666 permissions.  That should be sufficient, right?

Feel free to login to hp-xw8600-01.rhts.eng.bos.redhat.com beaker box and poke around.

It definitely seems to be a permissions problem:

# sudo -u qpidd ls /tmp/matahari/cert_db/
ls: cannot access /tmp/matahari/cert_db/: Permission denied

SELinux strikes again:

type=AVC msg=audit(1312488407.153:87928): avc:  denied  { read } for  pid=3850 comm="matahari-broker" name="tmp" dev=dm-0 ino=1179747 scontext=unconfined_u:system_r:qpidd_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir

Lets loop in someone from the selinux team here.

What are you trying to do?

Why would the cert db be installed under /tmp?

(In reply to comment #7)
> What are you trying to do?
> 
> Why would the cert db be installed under /tmp?

I'm assuming Dave is doing that just for testing but production will have its items under /var/lib/matahari

And all we are doing is reading the cert database for SSL capability

Thanks

Well if you are going to pick random directories for testing you need to make sure they are labeled correctly.

SELinux is a labelling system, if you change default locations you have to change the labels. 

If you look at the AVC above you see qpidd trying to read something in tmp_t and being denied, becasue qpidd is not allowed to read random content in /tmp.

Still getting some denied messages which ultimately prevent SSL initialization from working on a fresh system with certs created in /var/lib/matahari.  One error is still referencing tmp_t which is strange, its not in the configuration anywhere.  

type=SYSCALL msg=audit(1313008682.805:83227): arch=c000003e syscall=2 success=no exit=-13 a0=7fe41dcb7d57 a1=0 a2=1b6 a3=0 items=0 ppid=2985 pid=2986 auid=0 uid=498 gid=496 euid=498 suid=498 fsuid=498 egid=496 sgid=496 fsgid=496 tty=(none) ses=3 comm="matahari-broker" exe="/usr/sbin/qpidd" subj=unconfined_u:system_r:qpidd_t:s0 key=(null)
type=AVC msg=audit(1313008682.805:83228): avc:  denied  { read } for  pid=2986 comm="matahari-broker" name="tmp" dev=dm-0 ino=2228323 scontext=unconfined_u:system_r:qpidd_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir
type=SYSCALL msg=audit(1313008682.805:83228): arch=c000003e syscall=2 success=no exit=-13 a0=7fe41dcb7d53 a1=0 a2=1b6 a3=0 items=0 ppid=2985 pid=2986 auid=0 uid=498 gid=496 euid=498 suid=498 fsuid=498 egid=496 sgid=496 fsgid=496 tty=(none) ses=3 comm="matahari-broker" exe="/usr/sbin/qpidd" subj=unconfined_u:system_r:qpidd_t:s0 key=(null)
type=AVC msg=audit(1313008682.805:83229): avc:  denied  { read } for  pid=2986 comm="matahari-broker" name="tmp" dev=dm-0 ino=1966649 scontext=unconfined_u:system_r:qpidd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=lnk_file


[root@hp-dc5800-01 cert_db]# ls -lR /var/lib/matahari/
/var/lib/matahari/:
total 12
drw-rw-rw-. 2 qpidd qpidd 4096 Aug 10 16:31 cert_db
-rw-rw-rw-. 1 qpidd qpidd    9 Aug 10 16:31 cert.password
-rw-r-----. 1 qpidd qpidd    0 Aug 10 16:31 lock
-rw-r-----. 1 qpidd qpidd   37 Aug 10 16:31 systemId

/var/lib/matahari/cert_db:
total 96
-rw-rw-rw-. 1 qpidd qpidd 65536 Aug 10 16:31 cert8.db
-rw-rw-rw-. 1 qpidd qpidd 16384 Aug 10 16:31 key3.db
-rw-rw-rw-. 1 qpidd qpidd 16384 Aug 10 16:31 secmod.db


[root@hp-dc5800-01 cert_db]# cat /etc/matahari-broker.conf 
cluster-mechanism=ANONYMOUS
auth=no
ssl-cert-db=/var/lib/matahari/cert_db
ssl-cert-name=127.0.0.1
ssl-cert-password-file=/var/lib/matahari/cert.password
ssl-port=5674
log-enable="debug+"
log-to-file=/var/log/qpid/qpid.log
[root@hp-dc5800-01 cert_db]#

It appears the directory /var/lib/matahari has the label var_lib_t, and files added to it will inherit that label:

# ls -Zd /var/lib/matahari/
drwxr-xr-x. qpidd qpidd unconfined_u:object_r:var_lib_t:s0 /var/lib/matahari/

However, files created by matahari-brokerd (which is actually just qpidd) appear to have the label qpidd_var_lib_t:

# ls -ZR /var/lib/matahari/
/var/lib/matahari/:
drw-rw-rw-. qpidd qpidd unconfined_u:object_r:var_lib_t:s0 cert_db
-rw-rw-rw-. qpidd qpidd unconfined_u:object_r:var_lib_t:s0 cert.password
-rw-r--r--. root  root  unconfined_u:object_r:var_lib_t:s0 dave
-rw-r-----. qpidd qpidd unconfined_u:object_r:qpidd_var_lib_t:s0 lock
-rw-r-----. qpidd qpidd unconfined_u:object_r:qpidd_var_lib_t:s0 systemId

/var/lib/matahari/cert_db:
-rw-rw-rw-. qpidd qpidd unconfined_u:object_r:var_lib_t:s0 cert8.db
-rw-rw-rw-. qpidd qpidd unconfined_u:object_r:var_lib_t:s0 key3.db
-rw-rw-rw-. qpidd qpidd unconfined_u:object_r:var_lib_t:s0 secmod.db

I tried changing everything to have the label qpidd_var_lib_t, and that was enough to let the user qpidd access it:

# chcon -R unconfined_u:object_r:qpidd_var_lib_t:s0 /var/lib/matahari
# sudo -u qpidd ls -R /var/lib/matahari/
/var/lib/matahari/:
cert_db  cert.password	dave  lock  systemId

/var/lib/matahari/cert_db:
cert8.db  key3.db  secmod.db

matahari-brokerd is still not working, though:

# sudo -u qpidd matahari-brokerd --port 49000 --config /etc/matahari-broker.conf 
2011-08-11 05:42:03 notice SASL disabled: No Authentication Performed
2011-08-11 05:42:03 notice Listening on TCP port 49000
2011-08-11 05:42:03 error Failed to initialise SSL plugin: Failed: NSS error [-8174] (qpid/sys/ssl/util.cpp:103)
2011-08-11 05:42:03 notice Broker running

and that's weird because I don't get any AVC messages in the audit log from SELinux any more. Yet running it as root works, and the normal UNIX permissions appear correct.

So two questions, I guess:
1) How do we ensure that the directory /var/lib/matahari gets created with the context unconfined_u:object_r:qpidd_var_lib_t:s0?
2) What else is going on?

https://github.com/battlemidget/matahari/blob/master/matahari.spec

This is my spec file that creates a -selinux subpackage, however, when the directories are created I only see the following as far as selinux is concerned.

lz -Z /var/lib/

-rw-r--r--. root   root    system_u:object_r:logrotate_var_lib_t:s0 logrotate.status
drwxr-xr-x  root   root    ?                                matahari
drwxr-xr-x. root   root    system_u:object_r:var_lib_t:s0   misc
drwxr-x---. root   slocate system_u:object_r:locate_var_lib_t:s0 mlocate

Dan,

Any clue as to what I'm doing wrong?

Thanks

Miroslav can you add

/var/lib/matahari(/.*)?			gen_context(system_u:object_r:qpidd_var_lib_t,s0)

to qpid.fc in RHEL6.

Adam Are you sure the RPM expansion is doing what you want?  

Do you see the file context on disk?

I would look at what rpm -q matahari --scripts

And see what your post install is really doing.

(In reply to comment #14)
> Adam Are you sure the RPM expansion is doing what you want?  
> 
> Do you see the file context on disk?
> 
> I would look at what rpm -q matahari --scripts
> 
> And see what your post install is really doing.

From what I can tell it "looks" right?

postinstall scriptlet (using /bin/sh):
semanage fcontext -a -t qpidd_var_lib_t '/var/lib/matahari(/.*)?' >/dev/null 2>&1 || :
restorecon -R '/var/lib/matahari' || :
postuninstall scriptlet (using /bin/sh):
if [ $1 -eq 0 ]; then
   semanage fcontext -d -t qpidd_var_lib_t '/var/lib/matahari(/.*)?' >/dev/null 2>&1 || :
fi

semanage fcontext -l | grep matahari

root, ~  # semanage fcontext -l |grep matahari
/etc/rc\.d/init\.d/matahari-host                   all files          system_u:object_r:matahari_initrc_exec_t:s0 
/etc/rc\.d/init\.d/matahari-net                    all files          system_u:object_r:matahari_initrc_exec_t:s0 
/etc/rc\.d/init\.d/matahari-service                all files          system_u:object_r:matahari_initrc_exec_t:s0 
/usr/sbin/matahari-hostd                           regular file       system_u:object_r:matahari_hostd_exec_t:s0 
/usr/sbin/matahari-netd                            regular file       system_u:object_r:matahari_netd_exec_t:s0 
/usr/sbin/matahari-serviced                        regular file       system_u:object_r:matahari_serviced_exec_t:s0 
/var/lib/%{matahari}                               all files          system_u:object_r:qpidd_var_lib_t:s0 
/var/lib/matahari                                  all files          system_u:object_r:qpidd_var_lib_t:s0 
/var/lib/matahari(/.*)?                            all files          system_u:object_r:qpidd_var_lib_t:s0 
/var/lib/matahari/                                 all files          system_u:object_r:qpidd_var_lib_t:s0 
/var/lib/matahari/*                                all files          system_u:object_r:qpidd_var_lib_t:s0 
/var/run/matahari(/.*)?                            all files          system_u:object_r:matahari_var_run_t:s0 
/var/run/matahari-broker\.pid                      regular file       system_u:object_r:matahari_var_run_t:s0 
/var/run/matahari\.pid                             regular file       system_u:object_r:matahari_var_run_t:s0 

So it is working but my system is being wacky when displaying the contexts?

Looks like youhave had many tries at this...

semanage fcontext -D

Then reinstall your app, and see if the file context works.

Dave, 
what does

# rpm -q selinux-policy

# matchpathcon /var/lib/matahari



I see in the latest RHEL6 policy

optional_policy(`
    matahari_manage_lib_files(qpidd_t)
    matahari_manage_pid_files(qpidd_t)
')

and

/var/lib/matahari(/.*)?         gen_context(system_u:object_r:matahari_var_lib_t,s0)


So it shouldn't be needed.

This error is also present:

SELinux is preventing /usr/sbin/qpidd from write access on the file /run/matahari-broker.pid.

*****  Plugin catchall (50.5 confidence) suggests  ***************************

If you believe that qpidd should be allowed write access on the matahari-broker.pid file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep matahari-broker /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

*****  Plugin leaks (50.5 confidence) suggests  ******************************

If you want to ignore qpidd trying to write access the matahari-broker.pid file, because you believe it should not need this access.
Then you should report this as a bug.  
You can generate a local policy module to dontaudit this access.
Do
# grep /usr/sbin/qpidd /var/log/audit/audit.log | audit2allow -D -M mypol
# semodule -i mypol.pp


Do we need to make sure qpidd can access /run/matahari*?

Thanks

patch posted to ML to set qpid file context to /var/lib/matahari

/run/matahari* doesn't look right. It should at least be /var/run/matahari*

Miroslav,
can you please set correct selinux policies in selinux package? Do you need separate bug or something?

/var/run/matahari is in the RHEL6 policy package.


Adam please give us the actual avc messages?

We have +	matahari_manage_pid_files(qpidd_t)


Which should allow qpidd_t to manage any files labeled matahari_var_run_t.

selinux-policy-3.7.19-107.el6

I am still getting denied causing ssl initialization for the matahari broker to fail when the system has selinux-policy-3.7.19-107.  

One thing to note, notice matahari-0.4.2-7.el6.x86_64 is not installed because it has a dependency on matahari-selinux which we did not want installed to verify the fixes in comment 27 were sufficient.


[root@ibm-x3650-02 init.d]# rpm -qa | grep selinux
    selinux-policy-targeted-3.7.19-107.el6.noarch
    libselinux-utils-2.0.94-5.1.el6.x86_64
    libselinux-2.0.94-5.1.el6.x86_64
    libselinux-devel-2.0.94-5.1.el6.x86_64
    libselinux-python-2.0.94-5.1.el6.x86_64
    selinux-policy-3.7.19-107.el6.noarch

[root@ibm-x3650-02 init.d]# cat /var/log/audit/audit.log | audit2allow 
    #============= qpidd_t ==============
    allow qpidd_t tmp_t:dir read;
    allow qpidd_t usr_t:lnk_file read;

[root@ibm-x3650-02 init.d]# rpm -qa | grep matahari
    matahari-agent-lib-0.4.2-7.el6.x86_64
    matahari-consoles-0.4.2-7.el6.x86_64
    matahari-host-0.4.2-7.el6.x86_64
    matahari-lib-0.4.2-7.el6.x86_64
    matahari-broker-0.4.2-7.el6.x86_64
    matahari-network-0.4.2-7.el6.x86_64
    matahari-service-0.4.2-7.el6.x86_64
    matahari-sysconfig-0.4.2-7.el6.x86_64

Are you writing to /var/lib/matahari or /tmp? You should be writing to the former for your tests if not
[root@ibm-x3650-02 init.d]# cat /var/log/audit/audit.log | audit2allow 
    #============= qpidd_t ==============
    allow qpidd_t tmp_t:dir read;
    allow qpidd_t usr_t:lnk_file read;

Thanks

I added 

files_read_usr_files(qpidd_t)



Dave,
just execute these steps

# setenforce 0

re-test it

# ausearch -m avc -ts recent


will give you raw AVC msgs which we need to see.

[root@ibm-x3650-02 audit]# ausearch -m avc -ts recent
----
time->Mon Aug 22 10:02:04 2011
type=SYSCALL msg=audit(1314021724.862:129225): arch=c000003e syscall=2 success=yes exit=13 a0=3347641d57 a1=0 a2=1b6 a3=0 items=0 ppid=16258 pid=16259 auid=0 uid=499 gid=497 euid=499 suid=499 fsuid=499 egid=497 sgid=497 fsgid=497 tty=(none) ses=628 comm="matahari-broker" exe="/usr/sbin/qpidd" subj=unconfined_u:system_r:qpidd_t:s0 key=(null)
type=AVC msg=audit(1314021724.862:129225): avc:  denied  { read } for  pid=16259 comm="matahari-broker" name="tmp" dev=dm-0 ino=1441793 scontext=unconfined_u:system_r:qpidd_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir
----
time->Mon Aug 22 10:02:04 2011
type=SYSCALL msg=audit(1314021724.862:129226): arch=c000003e syscall=4 success=yes exit=0 a0=3347641d5c a1=7ffff2f8c0e0 a2=7ffff2f8c0e0 a3=22 items=0 ppid=16258 pid=16259 auid=0 uid=499 gid=497 euid=499 suid=499 fsuid=499 egid=497 sgid=497 fsgid=497 tty=(none) ses=628 comm="matahari-broker" exe="/usr/sbin/qpidd" subj=unconfined_u:system_r:qpidd_t:s0 key=(null)
type=AVC msg=audit(1314021724.862:129226): avc:  denied  { read } for  pid=16259 comm="matahari-broker" name="tmp" dev=dm-0 ino=524855 scontext=unconfined_u:system_r:qpidd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=lnk_file


[root@ibm-x3650-02 audit]# cat /etc/matahari-broker.conf 
cluster-mechanism=ANONYMOUS
auth=no
ssl-cert-db=/var/lib/matahari/cert_db
ssl-cert-name=127.0.0.1
ssl-cert-password-file=/var/lib/matahari/cert.password
ssl-port=5674
log-enable="debug+"
log-to-file=/var/log/qpid/qpid.log


[root@ibm-x3650-02 lib]# ls -lRZ matahari
matahari:
drw-rw-rw-. qpidd qpidd unconfined_u:object_r:matahari_var_lib_t:s0 cert_db
-rw-rw-rw-. qpidd qpidd unconfined_u:object_r:matahari_var_lib_t:s0 cert.password
-rw-r-----. qpidd qpidd unconfined_u:object_r:matahari_var_lib_t:s0 lock
-rw-r-----. qpidd qpidd unconfined_u:object_r:matahari_var_lib_t:s0 systemId

matahari/cert_db:
-rw-rw-rw-. qpidd qpidd unconfined_u:object_r:matahari_var_lib_t:s0 cert8.db
-rw-rw-rw-. qpidd qpidd unconfined_u:object_r:matahari_var_lib_t:s0 key3.db
-rw-rw-rw-. qpidd qpidd unconfined_u:object_r:matahari_var_lib_t:s0 secmod.db

Still seeing the same errors with v0.4.2-9...

Just to be clear, here is how I am setting up the ssl certs

cd /var/lib/matahari
echo password > cert.password
mkdir cert_db
cd cert_db/
certutil -N -d . -f /var/lib/matahari/cert.password
certutil -S -d /var/lib/matahari/cert_db -n 127.0.0.1 -s "CN=127.0.0.1" -t "CT,," -x -f /var/lib/matahari/cert.password -z /usr/bin/certutil
certutil -S -d /var/lib/matahari/cert_db -n agent -s "CN=agent" -t "CT,," -x -f /var/lib/matahari/cert.password -z /usr/bin/certutil
chown -R qpidd:qpidd /var/lib/matahari/cert*
chmod -R 666 /var/lib/matahari/cert*

#add the following /etc/matahari-broker.conf
#-------------------------------------------
ssl-cert-db=/var/lib/matahari/cert_db
ssl-cert-name=127.0.0.1
ssl-cert-password-file=/var/lib/matahari/cert.password
ssl-port=5674


[root@dell-pe6950-01 matahari]# ausearch -m avc -ts recent
----
time->Wed Aug 24 13:23:04 2011
type=SYSCALL msg=audit(1314206584.633:113819): arch=c000003e syscall=2 success=yes exit=12 a0=36bbe41d57 a1=0 a2=1b6 a3=0 items=0 ppid=10114 pid=10115 auid=0 uid=499 gid=497 euid=499 suid=499 fsuid=499 egid=497 sgid=497 fsgid=497 tty=(none) ses=3 comm="matahari-broker" exe="/usr/sbin/qpidd" subj=unconfined_u:system_r:qpidd_t:s0 key=(null)
type=AVC msg=audit(1314206584.633:113819): avc:  denied  { read } for  pid=10115 comm="matahari-broker" name="tmp" dev=dm-0 ino=917505 scontext=unconfined_u:system_r:qpidd_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir
----
time->Wed Aug 24 13:23:04 2011
type=SYSCALL msg=audit(1314206584.634:113820): arch=c000003e syscall=4 success=yes exit=0 a0=36bbe41d5c a1=7fff380d2300 a2=7fff380d2300 a3=22 items=0 ppid=10114 pid=10115 auid=0 uid=499 gid=497 euid=499 suid=499 fsuid=499 egid=497 sgid=497 fsgid=497 tty=(none) ses=3 comm="matahari-broker" exe="/usr/sbin/qpidd" subj=unconfined_u:system_r:qpidd_t:s0 key=(null)
type=AVC msg=audit(1314206584.634:113820): avc:  denied  { read } for  pid=10115 comm="matahari-broker" name="tmp" dev=dm-0 ino=1311305 scontext=unconfined_u:system_r:qpidd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=lnk_file

If you execute

# grep qpidd /var/log/audit/audit.log |audit2allow -M myqpidd
# semodule -i myqpidd

does it work in enforcing mode then?

No, still doesn't work with with the commands from comment 33.  I also did a fresh rhel install, disabled selinux, rebooted, installed v0.4.2-9 from brew, configured for ssl (comment 32), and still get the same error.

The only way I can get it to work is running:
    qpidd -p 49000 --config /etc/matahari-broker.conf

(In reply to comment #33)
> If you execute
> 
> # grep qpidd /var/log/audit/audit.log |audit2allow -M myqpidd
> # semodule -i myqpidd
> 
> does it work in enforcing mode then?

I am able to reproduce this easily with the same audit errors and we still fail to load our SSL module.

Im not sure if this will help clear up some things but below is how we start are service:

start() {
        echo -n $"Starting Matahari broker daemon: "
        install -o root -g qpidd -m 770 -d /var/lib/matahari
        install -o root -g qpidd -m 775 -d /var/run/matahari
        daemon --pidfile $pidfile --check $prog --user qpidd /usr/sbin/$prog --daemon --pid-dir /var/run/matahari --data-dir /var/lib/matahari $QPIDD_OPTIONS
        RETVAL=$?
        echo
        [ $RETVAL = 0 ] && touch $lockfile
        if [ $RETVAL = 0 ]; then
            touch $pidfile
            chown qpidd.qpidd $pidfile
            [ -x /sbin/restorecon ] && /sbin/restorecon $pidfile
            runuser -s /bin/sh qpidd -c "/usr/sbin/$prog --check --pid-dir /var/run/matahari $QPIDD_OPTIONS > $pidfile"
        fi
        return $RETVAL
}

Thanks
Adam

If it does not work in permissive mode then it is not SELinux issue.

Not sure whether it was tested in permissive mode?

# setenforce 0

a re-test it.

Dave,

Could you run the certificate creation portion as 'qpidd' user to verify it is not a simple permissions issue?

Thanks,
Adam

Still running into issues with this, on a fresh install this is what I did and ended up with a permission denied to bind to the port specified for ssl.  Nothing was already running on that port.



    5  wget http://download.devel.redhat.com/brewroot/packages/matahari/0.4.2/9.el6/x86_64/matahari-0.4.2-9.el6.x86_64.rpm

    6  wget http://download.devel.redhat.com/brewroot/packages/matahari/0.4.2/9.el6/x86_64/matahari-agent-lib-0.4.2-9.el6.x86_64.rpm

    7  wget http://download.devel.redhat.com/brewroot/packages/matahari/0.4.2/9.el6/x86_64/matahari-lib-0.4.2-9.el6.x86_64.rpm

    8  wget http://download.devel.redhat.com/brewroot/packages/matahari/0.4.2/9.el6/x86_64/matahari-host-0.4.2-9.el6.x86_64.rpm

    9  wget http://download.devel.redhat.com/brewroot/packages/matahari/0.4.2/9.el6/x86_64/matahari-network-0.4.2-9.el6.x86_64.rpm

   10  wget http://download.devel.redhat.com/brewroot/packages/matahari/0.4.2/9.el6/x86_64/matahari-service-0.4.2-9.el6.x86_64.rpm

   11  wget http://download.devel.redhat.com/brewroot/packages/matahari/0.4.2/9.el6/x86_64/matahari-sysconfig-0.4.2-9.el6.x86_64.rpm

   12  wget http://download.devel.redhat.com/brewroot/packages/matahari/0.4.2/9.el6/x86_64/matahari-consoles-0.4.2-9.el6.x86_64.rpm

   13  wget http://download.devel.redhat.com/brewroot/packages/matahari/0.4.2/9.el6/x86_64/matahari-debuginfo-0.4.2-9.el6.x86_64.rpm

   14  ls

   15  yum -y localinstall *rpm

   16  yum -y install nss-tools

   17  cd /var/lib/matahari

   18  sudo -u qpidd echo password > cert.password

   19  sudo -u qpidd mkdir cert_db

   20  cd cert_db/

   21  sudo -u qpidd certutil -N -d . -f /var/lib/matahari/cert.password

   22  sudo -u qpidd certutil -S -d /var/lib/matahari/cert_db -n 127.0.0.1 -s "CN=127.0.0.1" -t "CT,," -x -f /var/lib/matahari/cert.password -z /usr/bin/certutil

   23  sudo -u qpidd certutil -S -d /var/lib/matahari/cert_db -n agent -s "CN=agent" -t "CT,," -x -f /var/lib/matahari/cert.password -z /usr/bin/certutil

   24  mkdir /var/log/qpid

   25  touch /var/log/qpid/qpid.log

   26  chmod 666 /var/log/qpid/qpid.log

   27  vim /etc/matahari-broker.conf 



cluster-mechanism=ANONYMOUS

auth=no

ssl-cert-db=/var/lib/matahari/cert_db

ssl-cert-name=127.0.0.1

ssl-cert-password-file=/var/lib/matahari/cert.password

ssl-port=5674

log-enable="debug+"

log-to-file=/var/log/qpid/qpid.log





   28  /etc/init.d/matahari-broker start

   29  vim /var/log/qpid/qpid.log






2011-08-26 14:20:39 notice Listening on TCP port 49000

@@2011-08-26 14:20:39 debug Exception constructed: Can't bind to port 5674: Permission denied (qpid/sys/ssl/SslSocket.cpp:228)

@@2011-08-26 14:20:39 error Failed to initialise SSL plugin: Can't bind to port 5674: Permission denied (qpid/sys/ssl/SslSocket.cpp:228)

2011-08-26 14:20:39 info Policy file not specified. ACL Disabled, no ACL checking being done!

2011-08-26 14:20:39 debug Daemon ready on port: 49000

2011-08-26 14:20:39 notice Broker running

Using a fresh install with same steps above except for the SSL port to listen on (49001) I was able to successfully get the broker to load the ssl library.

Thanks,
Adam

Same here, with port 49001 SSL initialization successfully starts.  Marking this as good 2 go.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

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