Bug 201568 - sasl2 permission errors using SMTP AUTH and SMART_HOST
sasl2 permission errors using SMTP AUTH and SMART_HOST
Status: CLOSED INSUFFICIENT_DATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: cyrus-sasl (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Conklin
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-07 10:56 EDT by BYTRON
Modified: 2008-03-19 11:12 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-19 11:12:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description BYTRON 2006-08-07 10:56:21 EDT
I have been trying to configure my RHEL 4 server to forward all mail via another
SMTP server. I have set this up in the sendmail.mc (using the SMART_HOST
command). Also I required the server to authenticate itself using SMTP
authentication, I added the following line into /etc/mail/access

AuthInfo:domain "U:user" "I:user" "P:password" "R:domain" "M:PLAIN"

(with domain, user and password substituted with correct values).

I have rebuilt the hash of /etc/mail/access, made the sendmail.mc file and
restarted the sendmail service. But each time the service starts, the following
errors appear in /var/log/maillog


sendmail[21268]: error: safesasl(/usr/lib/sasl2/Sendmail.conf) failed: World
writable directory
sendmail[21268]: error: safesasl(/usr/lib/sasl2/libcrammd5.so.2) failed: World
writable directory
sendmail[21268]: error: safesasl(/usr/lib/sasl2/libplain.so.2) failed: World
writable directory
sendmail[21268]: error: safesasl(/usr/lib/sasl2/liblogin.so.2) failed: World
writable directory
sendmail[21268]: error: safesasl(/usr/lib/sasl2/libsasldb.so.2) failed: World
writable directory
sendmail[21268]: error: safesasl(/usr/lib/sasl2/libdigestmd5.so.2) failed: World
writable directory
sendmail[21268]: error: safesasl(/usr/lib/sasl2/libanonymous.so.2) failed: World
writable directory

I do not understand why these errors are being generated because /usr/lib/sasl2
is not world writeable: -

ls -ld /usr/lib/sasl2
drwxr-xr-x  2 root root 4096 Aug  7 14:55 /usr/lib/sasl2

Here are the permissions of the files in that directory (also not world
writeable): -

ls -l /usr/lib/sasl2/
total 1008
-rwxr-xr-x  1 root root    875 Dec  2  2004 libanonymous.la
lrwxrwxrwx  1 root root     22 Aug  7 14:55 libanonymous.so ->
libanonymous.so.2.0.19
lrwxrwxrwx  1 root root     22 Aug  7 14:55 libanonymous.so.2 ->
libanonymous.so.2.0.19
-rwxr-xr-x  1 root root  12820 Dec  2  2004 libanonymous.so.2.0.19
-rwxr-xr-x  1 root root    863 Dec  2  2004 libcrammd5.la
lrwxrwxrwx  1 root root     20 Aug  7 14:55 libcrammd5.so -> libcrammd5.so.2.0.19
lrwxrwxrwx  1 root root     20 Aug  7 14:55 libcrammd5.so.2 -> libcrammd5.so.2.0.19
-rwxr-xr-x  1 root root  15216 Dec  2  2004 libcrammd5.so.2.0.19
-rwxr-xr-x  1 root root    884 Dec  2  2004 libdigestmd5.la
lrwxrwxrwx  1 root root     22 Aug  7 14:55 libdigestmd5.so ->
libdigestmd5.so.2.0.19
lrwxrwxrwx  1 root root     22 Aug  7 14:55 libdigestmd5.so.2 ->
libdigestmd5.so.2.0.19
-rwxr-xr-x  1 root root  42964 Dec  2  2004 libdigestmd5.so.2.0.19
-rwxr-xr-x  1 root root    851 Dec  2  2004 liblogin.la
lrwxrwxrwx  1 root root     18 Aug  7 14:55 liblogin.so -> liblogin.so.2.0.19
lrwxrwxrwx  1 root root     18 Aug  7 14:55 liblogin.so.2 -> liblogin.so.2.0.19
-rwxr-xr-x  1 root root  13296 Dec  2  2004 liblogin.so.2.0.19
-rwxr-xr-x  1 root root    851 Dec  2  2004 libplain.la
lrwxrwxrwx  1 root root     18 Aug  7 14:55 libplain.so -> libplain.so.2.0.19
lrwxrwxrwx  1 root root     18 Aug  7 14:55 libplain.so.2 -> libplain.so.2.0.19
-rwxr-xr-x  1 root root  13360 Dec  2  2004 libplain.so.2.0.19
-rwxr-xr-x  1 root root    931 Dec  2  2004 libsasldb.la
lrwxrwxrwx  1 root root     19 Aug  7 14:55 libsasldb.so -> libsasldb.so.2.0.19
lrwxrwxrwx  1 root root     19 Aug  7 14:55 libsasldb.so.2 -> libsasldb.so.2.0.19
-rwxr-xr-x  1 root root 784960 Dec  2  2004 libsasldb.so.2.0.19
-rw-r--r--  1 root root     25 Jun  9 15:00 Sendmail.conf

This error seems to be stopping me sending mail as if I use the mail command to
send a test message I get the following in my maillog: -

AUTH=client, available mechanisms do not fulfill requirements
AUTH=client, relay=domain., temporary failure, connection abort
to=<email@domain>, ctladdr=<root@hostname> (0/0), delay=00:00:02,
xdelay=00:00:02, mailer=relay, pri=120344, relay=smtp.server. [correct IP],
dsn=4.0.0, stat=Deferred: Temporary AUTH failure.

Versions: -
sendmail-8.13.1-3.RHEL4.5
cyrus-sasl-2.1.19-5.EL4
cyrus-sasl-plain-2.1.19-5.EL4
Comment 1 Nalin Dahyabhai 2006-08-07 14:40:43 EDT
Just to rule it out, can you also check the permissions on /usr/lib, /usr, and /?
Comment 2 Thomas Woerner 2006-08-08 03:46:39 EDT
Why is this assigned to sendmail? Sendmail does not change permissions on any
files or directories in /usr.

If /usr, /usr/lib or /usr/lib/sasl2 is word writable, this is NO sendmail
problem, but sendmail reports this as an error.
Comment 3 BYTRON 2006-08-08 05:03:33 EDT
I checked the permissions of /usr/lib /usr and /. Each had somehow managed to
get 777 permissions set.

I have double checked the permissions of these directories on some RHEL and
non-RHEL systems, and they seem to be 755. I don’t know how this machines
directories managed to get these different permissions, but I’ll look into it.

I changed the directories back to 755 and restarted sendmail. The error messages
no longer show up in /var/log/maillog

Looks like this one can be closed as NOTABUG

Thanks for your help guys.
Comment 4 Nalin Dahyabhai 2006-08-08 09:41:15 EDT
Can you verify that there isn't a packaging problem (that the permissions
weren't changed as part of a package installation)?  To do so, run:
  rpm -qf /
  rpm -qf /usr
  rpm -qf /usr/lib

For each package which is listed as an owner for these directories, run:
  rpm -qlv PACKAGENAME | egrep '(/|/usr|/usr/lib)$'

This will give you a list of what permissions each package attempts to apply to
these directories.  If any of them shows that the package dictates that the
permissions should be 777, then you've found a bug in that package.

(I found a few packages which claim to own /usr/lib on my development box, but
they all agreed on the permissions, and that's not a big problem.)

Thanks!

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