Bug 759334
| Summary: | Saslauthd fails to authenticate | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jeffrey Ross <jeff> |
| Component: | cyrus-sasl | Assignee: | Petr Lautrbach <plautrba> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 16 | CC: | erik, plautrba, tmraz |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | cyrus-sasl-2.1.23-27.fc16 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-01-02 21:53:19 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 816135 | ||
Exactly the same problem here. Upgrading with yum from Fedora 14. Using cyrus-sasl-2.1.23-25.fc16.i686 Also tested with authentication methods shadow and getpwent. /usr/sbin/saslauthd -a pam -d saslauthd[19797] :main : num_procs : 5 saslauthd[19797] :main : mech_option: NULL saslauthd[19797] :main : run_path : /var/run/saslauthd saslauthd[19797] :main : auth_mech : pam saslauthd[19797] :ipc_init : using accept lock file: /var/run/saslauthd/mux.accept saslauthd[19797] :detach_tty : master pid is: 0 saslauthd[19797] :ipc_init : listening on socket: /var/run/saslauthd/mux saslauthd[19797] :main : using process model saslauthd[19797] :have_baby : forked child: 19798 saslauthd[19797] :have_baby : forked child: 19799 saslauthd[19797] :have_baby : forked child: 19800 saslauthd[19797] :have_baby : forked child: 19801 saslauthd[19797] :get_accept_lock : acquired accept lock saslauthd[19797] :rel_accept_lock : released accept lock saslauthd[19801] :get_accept_lock : acquired accept lock After this saslauthd just does nothing and testsaslauthd receives no answer. After killing the process there's some more debugging info: saslauthd[19797] :server_exit : pid file lock removed: /var/run/saslauthd/saslauthd.pid.lock saslauthd[19797] :ipc_cleanup : accept lock file removed: /var/run/saslauthd/mux.accept saslauthd[19797] :ipc_cleanup : socket removed: /var/run/saslauthd/mux saslauthd[19797] :server_exit : master exited: 0 saslauthd[19800] :server_exit : child exited: 19800 saslauthd[19801] :server_exit : child exited: 19801 saslauthd[19798] :server_exit : child exited: 19798 saslauthd[19799] :server_exit : child exited: 19799 Problem here is patch cyrus-sasl-2.1.23-pam_rhosts.patch introducing logging of the remote host via PAM. Unfortunately this patch doesn't change testsaslauthd in order to send client address so saslauthd tries to read data which never come. Are there any other problems with software different from testsaslauthd? I've tried to configure postfix with cyrus-sasl and authentication works as expected - postfix sends also client addr. I will either change this patch or remove it completely if it makes problems other than non-function testsaslauthd. Authentication fails in the same manner when using the supplied version of Exim with SMTP authentication against saslauthd Exim tries to directly communicate with the saslauthd instead of using proper cyrus-sasl library calls. I am not really sure how is this approach common among the various sasl clients. I'd probably propose dropping the patch for now at least until it or adjusted patch is accepted upstream. To make the patch non-intrusive there would have to be some way to distinguish between saslauthd clients which send the rhost and which do not making the patch backwards compatible. I'm using testsaslautd in a PHP script to authenticate system users. This may not be the best or the safest way to do this, but system user authentication is notoriously difficult to do in PHP (I don't want to give Apache access to the /etc/shadow file), so I'm using a call to testsaslauthd. I think I'm not the only one who's doing this, so I'd like one of twho things: either have the patch removed until there's also a patch for testsaslauthd, or to have the patch altered in such a way as to take into account that requesting programs don't send a client address. cyrus-sasl-2.1.23-27.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/cyrus-sasl-2.1.23-27.fc16 Package cyrus-sasl-2.1.23-27.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing cyrus-sasl-2.1.23-27.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-17029/cyrus-sasl-2.1.23-27.fc16 then log in and leave karma (feedback). cyrus-sasl-2.1.23-27.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. |
Description of problem: cyrus-sasl fails to authenticate and hangs Version-Release number of selected component (if applicable): cyrus-sasl-2.1.23-25.fc16.x86_64 How reproducible: every time, tested on 2 systems both were upgraded via yum from Fedora 15 to 16 Steps to Reproduce: 1. install cyrus-sasl 2. run "testsaslauthd -u {username} -p {password} -s smtp -f /var/run/saslauthd/mux" Actual results: Nothing happens Expected results: 0: OK "Success." Additional info: output from strace: fcntl(6, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=0, len=1}{sa_family=AF_FILE, NULL}, [2]) = 7 fcntl(6, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=1}) = 0 ) = 0 accept(5, read(7, "\0\4", 2) = 2 read(7, "myusername", 4) = 4 read(7, "\0\6", 2) = 2 read(7, "mypassword", 6) = 6 read(7, "\0\4", 2) = 2 read(7, "smtp", 4) = 4 read(7, "\0\0", 2) = 2 read(7, Attempt to authenticate against shadow resulted in a failure at the same place according to strace. a compile of cyrus-sasl 2.1.25 from source worked properly with no other changes to the system.