0

If I run saslauthd via svcadm it does not work, but if I run it from the command-line, it does.

u@h:w$ svcadm enable saslauthd                                          
u@h:w$ ps -ef|grep sasl                                                 
    root 17192 14073   0 05:50:12 ?           0:00 /opt/ooce/sbin/saslauthd -a sasldb -c -m /var/run/saslauthd
    root 17194 17102   0 05:50:31 pts/3       0:00 grep sasl
u@h:w$ /opt/ooce/sbin/testsaslauthd -p topsikrit -u imapuser
0: NO "authentication failed"
u@h:w$ svcadm disable saslauthd                                         
u@h:w$ /opt/ooce/sbin/saslauthd -a sasldb -c -d -V -m /var/run/saslauthd
saslauthd[17211] :num_procs  : 5
saslauthd[17211] :mech_option: NULL
saslauthd[17211] :run_path   : /var/run/saslauthd
saslauthd[17211] :auth_mech  : sasldb
...

[ switch to another tty]

u@h:w$ /opt/ooce/sbin/testsaslauthd -p topsikrit -u imapuser
0: OK "Success."

The only difference, so far as I can see, between the two modes of running of saslauthd is that one was launched by the svcadm framework and the other, from the command line. But the user (root -- despite the $ in the prompt) is the same, and the arguments, (apart from -V and -d) are also the same. So why won't saslauthd authenticate in the first case, but will in the second?

The above commands were run in a sparse zone.

Everything works as it should if I switch to the passwd mechanism but I would prefer to use sasldb.

Michael NGV
  • 1
  • 1

1 Answers1

0

In case this helps anybody else, the SASL DB was:

# ls -l /var/opt/ooce/sasl2/
total 172
-rw-r-----   1 cyrus    cyrus      32768 May  9 03:30 sasldb2
-rw-r-----   1 cyrus    cyrus       8192 May  9 22:30 sasldb2-lock

and it works if you chmod go+rw those two files. I know that they are created owned by root, but I found separately that that prevents successful authentication by a Cyrus server; although maybe the answer is the permissions, and not the ownership.

Michael NGV
  • 1
  • 1