Bug#866973: cyrus-imapd 3.0 needs to be (eventually) packaged
Ond, I may have some time the week after next to assist. Any contributions I'd have would be external. On 01/05/18 11:41 +0100, Ondřej Surý wrote: Yes, the maintainer is active. I started cyrus-imapd 3.0 packaging while ago and it's noticeable amount of work, so if anybody else want to join the packaging team and do the heavylifting before a bigger time window of free time opens for me, they would be welcome. I would be happy to convert the cyrus-imapd packaging to salsa.debian.org, so it's easier for external contributors to add code. O. -- Ondřej Surý On Mon, Jan 1, 2018, at 20:36, Berhardt Eckl wrote: Does anybody know if maintainer is still active on this package? Is there any reason why updates are not packaged? Thx
Bug#731954: Patch for crypted passwords in db
On 11/09/15 19:29 +0300, Max Kosmach wrote: Hi I have found patch for earlier version of cyrus-sasl that adds an ability to use encrypted passwords in db. Patch uses unix crypt(). http://pieps.org/cyrus/dist/2.1.19/cyrus-sasl-2.1.19-checkpw.c.patch Would You please apply this or similar patch to cyrus sasl debian package? There is a partially implemented, and undocumented 'pwcheck_method: auxprop-hashed' feature in the code. I believe it supports both sql and sasldb auxprop backends but not ldapdb. See git commit 62ce0768aa375cf0d16102570970b232dcb1cb28 -- Dan White
Bug#798630: sasl2-bin: saslauthd rimap error with dovecot-imapd
On 09/11/15 11:06 +0200, David Cure wrote: Package: sasl2-bin Version: 2.1.26.dfsg1-13 Severity: normal Dear Maintainer, I configure saslauthd (for use with sendmail) to use rimap to authenticate against dovecote-imapd. Every time, I get this error message : saslauthd[8707]: do_auth : auth failure: [user=] [service=smtp] [realm=] [mech=rimap] [reason=[ALERT] Unexpected response from remote authentication server] and after several try (and error), the user succeed to authenticate I check in the dovecot-log and no error (I have the same configuration on wheezy and no problem) Any idea ? This is an upstream bug: https://bugzilla.cyrusimap.org/show_bug.cgi?id=3209 The imap backend needs work. -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages sasl2-bin depends on: ii db-util5.3.0 ii debconf [debconf-2.0] 1.5.56 ii libc6 2.19-18 ii libcomerr2 1.42.12-1.1 ii libdb5.3 5.3.28-9 ii libgssapi-krb5-2 1.12.1+dfsg-19 ii libk5crypto3 1.12.1+dfsg-19 ii libkrb5-3 1.12.1+dfsg-19 ii libldap-2.4-2 2.4.40+dfsg-1 ii libpam0g 1.1.8-3.1 ii libsasl2-2 2.1.26.dfsg1-13 ii libssl1.0.01.0.1k-3+deb8u1 sasl2-bin recommends no packages. sasl2-bin suggests no packages. -- Configuration Files: /etc/default/saslauthd changed: START=yes DESC="SASL Authentication Daemon" NAME="saslauthd" MECHANISMS="rimap" MECH_OPTIONS="localhost" THREADS=20 OPTIONS="-c -m /var/run/saslauthd" -- debconf information: cyrus-sasl2/upgrade-sasldb2-backup-failed: cyrus-sasl2/purge-sasldb2: false cyrus-sasl2/upgrade-sasldb2-failed: cyrus-sasl2/backup-sasldb2: /var/backups/sasldb2.bak
Bug#784112: /usr/sbin/saslauthd: saslauthd segfaults
Thomas, I've installed a standard jessie/amd64 installation running the same versions you are and I cannot reproduce. I've tried testsaslauthd, pop3d, and smtptest using both a known good username and a bad username (webmaster), using a for loop to simulate rapid connections. If you can enable core dumps for saslauthd, and install libc6-dbg and cyrus-sasl2-dbg, in your production environment, please obtain a gdb backtrace. On 05/12/15 16:09 +0200, Thomas Kupka wrote: Dan, the only lead I could have is a correlation between peaks of failed login attempts (from malicious sources most likely, at a rate of precisely one attempt every 5 seconds) and the segfaults. Does this help? extract from mail.log: May 10 10:17:50 mail cyrus/pop3[23539]: badlogin: no-data [60.29.221.174] plaintext test SASL(-13): authentication failure: checkpass failed May 10 10:17:55 mail cyrus/pop3[23540]: badlogin: no-data [60.29.221.174] plaintext test SASL(-13): authentication failure: checkpass failed May 10 10:18:00 mail cyrus/pop3[23541]: badlogin: no-data [60.29.221.174] plaintext test SASL(-13): authentication failure: checkpass failed extract from messages: May 10 10:18:09 mail kernel: [641457.138137] saslauthd[18768]: segfault at 0 ip 7fdf751b8c8a sp 7ffd3cf92e58 error 4 in libc-2.19.so [7fdf75137000+19f000] May 10 10:18:14 mail kernel: [641461.917719] saslauthd[18773]: segfault at 0 ip 7fdf751b8c8a sp 7ffd3cf92e58 error 4 in libc-2.19.so [7fdf75137000+19f000] May 10 10:18:19 mail kernel: [641466.650182] saslauthd[18764]: segfault at 0 ip 7fdf751b8c8a sp 7ffd3cf92e58 error 4 in libc-2.19.so [7fdf75137000+19f000] After this peak was over, there have been no more segfaults for the next 8 hours. On Tue, May 12, 2015 at 3:42 PM, Dan White wrote: Thomas, Can you provide a reproducible case? e.g., does this happen on the first authentication attempt after starting saslauthd (with the shadow backend), or are there other factors at play that you can identify? On 05/12/15 11:08 +0200, Thomas Kupka wrote: I have changed the backend to pam and had no segfaults for the last 3 days. Seem like only the shadow backend has this issue. On Fri, May 8, 2015 at 9:10 AM, Thomas Kupka wrote: On Wed, 6 May 2015 09:10:15 -0500 Dan White wrote: > Can you get a backtrace from the core dump, and debug output, e.g.: > > saslauthd -d -c -m /var/spool/postfix/ It does not seem that debug gives out any interesting information. Here are the last lines from when the child processes died: saslauthd[19194] :do_auth : auth success: [user=thomas] [service=imap] [realm=] [mech=shadow] saslauthd[19194] :do_request : response: OK saslauthd[19195] :rel_accept_lock : released accept lock saslauthd[19193] :get_accept_lock : acquired accept lock saslauthd[19193] :rel_accept_lock : released accept lock saslauthd[19194] :get_accept_lock : acquired accept lock saslauthd[19193] :do_auth : auth failure: [user=noauth] [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] saslauthd[19194] :rel_accept_lock : released accept lock saslauthd[19193] :get_accept_lock : acquired accept lock saslauthd[19194] :do_auth : auth failure: [user=spam] [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] saslauthd[19193] :rel_accept_lock : released accept lock saslauthd[19193] :do_auth : auth failure: [user=test] [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] saslauthd[19194] :get_accept_lock : acquired accept lock saslauthd[19194] :rel_accept_lock : released accept lock saslauthd[19194] :do_auth : auth failure: [user=info] [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] saslauthd[19193] :get_accept_lock : acquired accept lock saslauthd[19193] :rel_accept_lock : released accept lock saslauthd[19193] :do_auth : auth failure: [user=admin] [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] saslauthd[19194] :get_accept_lock : acquired accept lock saslauthd[19194] :rel_accept_lock : released accept lock saslauthd[19194] :do_auth : auth failure: [user=administrator] [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] saslauthd[19193] :get_accept_lock : acquired accept lock saslauthd[19193] :rel_accept_lock : released accept lock saslauthd[19194] :get_accept_lock : acquired accept lock saslauthd[19194] :rel_accept_lock : released accept lock saslauthd[19194] :do_auth : auth failure: [user=postmaster] [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] saslauthd[19194] :get_accept_lock : acquired accept lock saslauthd[19194] :rel_accept_lock : released accept lock saslauthd[19194] :do_auth : auth failure: [user=sales] [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] saslauthd[19194] :get_accept_lock : acquired accept lock saslauthd[19194] :rel_accept_lock : released accept lock saslauthd[19194] :do_auth : auth failure: [user=support] [service=s
Bug#784112: /usr/sbin/saslauthd: saslauthd segfaults
Thomas, Can you provide a reproducible case? e.g., does this happen on the first authentication attempt after starting saslauthd (with the shadow backend), or are there other factors at play that you can identify? On 05/12/15 11:08 +0200, Thomas Kupka wrote: I have changed the backend to pam and had no segfaults for the last 3 days. Seem like only the shadow backend has this issue. On Fri, May 8, 2015 at 9:10 AM, Thomas Kupka wrote: On Wed, 6 May 2015 09:10:15 -0500 Dan White wrote: > Can you get a backtrace from the core dump, and debug output, e.g.: > > saslauthd -d -c -m /var/spool/postfix/ It does not seem that debug gives out any interesting information. Here are the last lines from when the child processes died: saslauthd[19194] :do_auth : auth success: [user=thomas] [service=imap] [realm=] [mech=shadow] saslauthd[19194] :do_request : response: OK saslauthd[19195] :rel_accept_lock : released accept lock saslauthd[19193] :get_accept_lock : acquired accept lock saslauthd[19193] :rel_accept_lock : released accept lock saslauthd[19194] :get_accept_lock : acquired accept lock saslauthd[19193] :do_auth : auth failure: [user=noauth] [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] saslauthd[19194] :rel_accept_lock : released accept lock saslauthd[19193] :get_accept_lock : acquired accept lock saslauthd[19194] :do_auth : auth failure: [user=spam] [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] saslauthd[19193] :rel_accept_lock : released accept lock saslauthd[19193] :do_auth : auth failure: [user=test] [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] saslauthd[19194] :get_accept_lock : acquired accept lock saslauthd[19194] :rel_accept_lock : released accept lock saslauthd[19194] :do_auth : auth failure: [user=info] [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] saslauthd[19193] :get_accept_lock : acquired accept lock saslauthd[19193] :rel_accept_lock : released accept lock saslauthd[19193] :do_auth : auth failure: [user=admin] [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] saslauthd[19194] :get_accept_lock : acquired accept lock saslauthd[19194] :rel_accept_lock : released accept lock saslauthd[19194] :do_auth : auth failure: [user=administrator] [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] saslauthd[19193] :get_accept_lock : acquired accept lock saslauthd[19193] :rel_accept_lock : released accept lock saslauthd[19194] :get_accept_lock : acquired accept lock saslauthd[19194] :rel_accept_lock : released accept lock saslauthd[19194] :do_auth : auth failure: [user=postmaster] [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] saslauthd[19194] :get_accept_lock : acquired accept lock saslauthd[19194] :rel_accept_lock : released accept lock saslauthd[19194] :do_auth : auth failure: [user=sales] [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] saslauthd[19194] :get_accept_lock : acquired accept lock saslauthd[19194] :rel_accept_lock : released accept lock saslauthd[19194] :do_auth : auth failure: [user=support] [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] saslauthd[19194] :get_accept_lock : acquired accept lock saslauthd[19194] :rel_accept_lock : released accept lock saslauthd[19194] :do_auth : auth failure: [user=webmaster] [service=smtp] [realm=] [mech=shadow] [reason=Incorrect password] saslauthd[19194] :get_accept_lock : acquired accept lock saslauthd[19194] :rel_accept_lock : released accept lock saslauthd[19194] :do_auth : auth failure: [user=help] [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] saslauthd[19194] :get_accept_lock : acquired accept lock saslauthd[19194] :rel_accept_lock : released accept lock saslauthd[19194] :do_auth : auth failure: [user=contact] [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] saslauthd[19194] :get_accept_lock : acquired accept lock saslauthd[19194] :rel_accept_lock : released accept lock saslauthd[19194] :do_auth : auth failure: [user=office] [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] saslauthd[19194] :get_accept_lock : acquired accept lock saslauthd[19194] :rel_accept_lock : released accept lock saslauthd[19194] :do_auth : auth failure: [user=staff] [service=smtp] [realm=] [mech=shadow] [reason=Invalid username] saslauthd[19194] :get_accept_lock : acquired accept lock saslauthd[19194] :rel_accept_lock : released accept lock The failed authentication attempts are certainly malicious software trying out default credentials but they seem to be handled normally. > This backend doesn't get used much these days. pam should functionally > replace it. Does it also produce a segfault? I will try this. I have shadow backend running for about 10 years now and never had this urge to change it. Thomas On Wed, May 6, 2015 at 4:10
Bug#784112: /usr/sbin/saslauthd: saslauthd segfaults
On 05/03/15 10:24 +0200, Thomas Kupka wrote: Package: sasl2-bin Version: 2.1.26.dfsg1-13 Severity: important File: /usr/sbin/saslauthd Dear Maintainer, since upgrading to Jessie, all saslauthd processes segfault on a multiple daily basis: May 3 06:26:12 mail kernel: [22739.740552] saslauthd[763]: segfault at 0 ip 7faffd5d8c8a sp 7ffda85ebe48 error 4 in libc-2.19.so[7faffd557000+19f000] May 3 06:26:12 mail kernel: [22739.928344] saslauthd[739]: segfault at 0 ip 7faffd5d8c8a sp 7ffda85ebe48 error 4 in libc-2.19.so[7faffd557000+19f000] May 3 06:26:12 mail kernel: [22740.127304] saslauthd[760]: segfault at 0 ip 7faffd5d8c8a sp 7ffda85ebe48 error 4 in libc-2.19.so[7faffd557000+19f000] May 3 10:04:24 mail kernel: [35831.420577] saslauthd[761]: segfault at 0 ip 7faffd5d8c8a sp 7ffda85ebe48 error 4 in libc-2.19.so[7faffd557000+19f000] May 3 10:04:24 mail kernel: [35831.607218] saslauthd[762]: segfault at 0 ip 7faffd5d8c8a sp 7ffda85ebe48 error 4 in libc-2.19.so[7faffd557000+19f000] May 3 10:04:24 mail postfix/smtpd[17269]: warning: SASL authentication failure: cannot connect to saslauthd server: Connection refused Can you get a backtrace from the core dump, and debug output, e.g.: saslauthd -d -c -m /var/spool/postfix/var/run/saslauthd -a shadow I can't reproduce your segfault on my unstable system running 2.1.26.dfsg1-13. However, I'm several version behind on some of the linked libraries. -- Configuration Files: /etc/default/saslauthd changed: START=yes DESC="SASL Authentication Daemon" NAME="saslauthd" MECHANISMS="shadow" This backend doesn't get used much these days. pam should functionally replace it. Does it also produce a segfault? -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#758660: sasl2-bin: saslauthd "Memory buffer error"
On 08/20/14 21:58 +0200, Martin Sebald wrote: So does the work around work anyway? It seems that I not fully understand what is going on. Anyway, if I restart saslauthd after the problem is there everything works right away like there was never a problem. Yes, it should, since saslauthd spawns a new process (-n 0) with each authentication attempt. The memory gets freed when the process ends even though there's a memory leak. You'll hide the problem at the expense of process setup/tear down overhead. -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#758660: sasl2-bin: saslauthd "Memory buffer error"
On 08/20/14 20:47 +0200, Martin Sebald wrote: /etc/default/saslauthd: START=yes DESC="SASL Authentication Daemon" NAME="saslauthd" MECHANISMS="pam" MECH_OPTIONS="" #THREADS=5 THREADS=0 OPTIONS="-r -c -m /var/spool/postfix/var/run/saslauthd" (I just changed threads from 5 to 0, thank you for the hint and the maybe workaround for this problem.) I do not have a /etc/saslauthd.conf config file. I use pam only, do you need the config files as well? Just a list of PAM modules should be sufficient, or perhaps the configuration is you're using something less usual (such as a *sql module). My belief is that this type of issue is due to a memory leak in the specific PAM module, or due to the way saslauthd uses pam - it only uses the auth and account facilities and not the session or password facilities, which may prevent the module from performing it's memory cleanup. -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#758660: sasl2-bin: saslauthd "Memory buffer error"
On 08/19/14 20:00 +0200, Martin Sebald wrote: Package: sasl2-bin Version: 2.1.26.dfsg1-11 Severity: important Hi, the saslauthd fails here on our mail server for weeks now. It seems that after a certain amount of login (successful and tries) a limit is reached and the daemon silently (!) fails - people cannot log into SASL-Auth anymore. I see the following in the log: Aug 19 19:44:41 server saslauthd[25483]: DEBUG: auth_pam: pam_authenticate failed: Memory buffer error After restarting everything works again until it happens again. We use cron to restart saslauthd every hour now, the only solution at the moment. Martin, Please provide details of your saslauthd config, /etc/default/saslauthd and /etc/saslauthd.conf if you have one, and a list of which pam modules you are using. For a likely work around for this issue, see option '-n' in the saslauthd manpage. Thanks, -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#746511: sasl2-bin: memory leak
On 04/30/14 22:04 +0200, Andreas Edler wrote:
Package: sasl2-bin
Version: 2.1.23.dfsg1-7
Severity: important
Over time saslauthd will grab more and more "apps memory", and it appears
it never frees it up again.
Find attached a memory usage graph. The drops in usage are a result of
restarting saslauthd only, nothing else has been done at these times.
-- System Information:
Debian Release: 6.0.9
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages sasl2-bin depends on:
ii db4.8-util 4.8.30-2 Berkeley v4.8 Database Utilities
ii debconf [debconf-2. 1.5.36.1 Debian configuration management sy
ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib
ii libcomerr2 1.41.12-4stable1 common error description library
ii libdb4.84.8.30-2 Berkeley v4.8 Database Libraries [
ii libgssapi-krb5-21.8.3+dfsg-4squeeze7 MIT Kerberos runtime libraries - k
ii libk5crypto31.8.3+dfsg-4squeeze7 MIT Kerberos runtime libraries - C
ii libkrb5-3 1.8.3+dfsg-4squeeze7 MIT Kerberos runtime libraries
ii libkrb5support0 1.8.3+dfsg-4squeeze7 MIT Kerberos runtime libraries - S
ii libldap-2.4-2 2.4.23-7.3 OpenLDAP libraries
ii libpam0g1.1.1-6.1+squeeze1 Pluggable Authentication Modules l
ii libsasl2-2 2.1.23.dfsg1-7 Cyrus SASL - authentication abstra
ii libssl0.9.8 0.9.8o-4squeeze14SSL shared libraries
ii lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip
sasl2-bin recommends no packages.
sasl2-bin suggests no packages.
-- Configuration Files:
/etc/default/saslauthd changed:
START=yes
DESC="SASL Authentication Daemon"
NAME="saslauthd"
MECHANISMS="pam"
MECH_OPTIONS=""
THREADS=1
OPTIONS="-m /var/spool/postfix/var/run/saslauthd -r"
PWDIR="/var/spool/postfix/var/run/saslauthd"
PARAMS="-m ${PWDIR}"
PIDFILE="${PWDIR}/saslauthd.pid"
-- debconf information:
cyrus-sasl2/backup-sasldb2: /var/backups/sasldb2.bak
cyrus-sasl2/upgrade-sasldb2-failed:
cyrus-sasl2/upgrade-sasldb2-backup-failed:
cyrus-sasl2/purge-sasldb2: false
Please provide the PAM module(s) which are at play here.
--
Dan White
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#731954: libsasl2-modules-sql: Support password_format: crypt for sql
On 12/11/13 07:49 -0800, alex wrote: Package: libsasl2-modules-sql Version: 2.1.25.dfsg1-6+deb7u1 Severity: wishlist Dear Maintainer, Encrypting the password in an sql database for sasl2 to use has been a long outstanding feature that needs to be fixed. There are currently a few methods of resolving the issue but they involve outdated patches as well as installing other packages as a work around to the solution. Fixing this issue could help resolve a major issue with sql databases and sasl2 and help promote cyrus as imap server. The issue in question is the lack of support for the password_format: crypt option. As online security is ever more important this day and age, storing plain text passwords in a database isn't an acceptable use case. This functionality has been included with other libsasl2-modules-* packages. I honestly haven't found an answer as to why this functionality hasn't been included. If there is a reason, I apologize for the bug report but would also like an explanation so that I may document it accordingly. Thank you for your time. I look forward to answering any more questions you may have about this issue and/or what the current fixes look like. ii libsasl2-modules 2.1.25.dfsg1-6+deb7u1 Recent versions of libsasl2 (including cyrus-sasl2 2.1.25.dfsg1-17) contain support for pwcheck_method: auxprop-hashed, but unfortunately is undocumented. The source leads me to believe that the stored value should me an md5 hash of the shared secret. This functionality has not been implemented in all auxprop plugins (including ldapdb), due to the fact that it is undocumented. -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#703113: libsasl2-modules-gssapi-mit: Java client GSSAPI connections to OpenLDAP fail
hemaRunnable.reloadSchema(ReloadSchemaRunnable.java:147) at org.apache.directory.studio.ldapbrowser.core.BrowserConnectionListener.openBrowserConnection(BrowserConnectionListener.java:115) at org.apache.directory.studio.ldapbrowser.core.BrowserConnectionListener.connectionOpened(BrowserConnectionListener.java:65) at org.apache.directory.studio.connection.core.jobs.OpenConnectionsRunnable.runNotification(OpenConnectionsRunnable.java:132) at org.apache.directory.studio.connection.core.jobs.StudioConnectionJob.run(StudioConnectionJob.java:120) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) On the client we have tried sun-java6, openjdk-6, and openjdk-7 with the similiar failures. We do not see this problem on our squeeze systems using version 2.1.23.dfsg1-8 of libsasl2-modules-gssapi-mit. We do see the same problem if we use libsasl2-modules-gssapi-heimdal instead of libsasl2-modules-gssapi-mit. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/16 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages libsasl2-modules-gssapi-mit depends on: ii libc6 2.13-38 ii libcomerr21.42.5-1 ii libgssapi-krb5-2 1.10.1+dfsg-4 ii libk5crypto3 1.10.1+dfsg-4 ii libkrb5-3 1.10.1+dfsg-4 ii libsasl2-modules 2.1.25.dfsg1-6 ii libssl1.0.0 1.0.1e-1 libsasl2-modules-gssapi-mit recommends no packages. libsasl2-modules-gssapi-mit suggests no packages. -- no debconf information -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#696563: slapd not ready when start script exits, plase add sleep in starting script
On 12/23/12 02:27 +0100, Fabien C. wrote: Hello, This is absolutely not an acceptable fix for this bug. A 'sleep' only reduces the frequency of a race, it does not eliminate it. Yes, I totally agree, it would only be a dirty workaround. However, when the issue is complicated to fix, I think that reducing problem frequency in the meanwhile is a good thing, especially when it takes 2 minutes to be done. Then, we can try to find and correct the *source* of the problem, fixing it and remove the ugly workaround. Please don't get suckered in to this form of thinking. I have a proprietary service at work that takes > 20 minutes to start up, on a redhat system. It's Java based, and has several different processes that it starts up. It's solution for process interdependencies is to sleep 60 seconds, or 300 seconds, or X seconds before starting the next process. Every release seems to get a slower startup time too. I suspect the developers have found corner cases and received support calls where some system condition caused something to not get started within that expected sleep window, and they just increase the sleep time. I have a gripe with systems that don't handle ldap server (or networking) failure properly, and require a restart of that process in the event an ldap connection times out. Bind is also at fault here for not taking such conditions into account. -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#520417: Remove need of 'sed' from /etc/network/*.d/vlan and consolidate to one script
I ran into a problem with the vlan if-pre-up.d script that is mentioned in
this bug.
I've renamed an interface on my firewall like so:
$ grep inside /etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \
ATTR{address}=="00:a0:c9:c5:33:f2", ATTR{dev_id}=="0x0", \
ATTR{type}=="1", KERNEL=="eth*", NAME="eth-inside"
When attempting to configure and entry in /etc/network/interfaces, such as:
auto eth-inside.4
iface eth-inside.4 inet static
address 192.168.4.1
network 192.168.4.0
netmask 255.255.255.0
broadcast 192.168.4.255
vlan-raw-device eth-inside
The vlan script fails to create the vlan subinterface.
A work around is:
auto eth-inside.4
iface eth-inside.4 inet static
address 192.168.4.1
network 192.168.4.0
netmask 255.255.255.0
broadcast 192.168.4.255
pre-up vconfig add eth-inside 4
--
Dan White
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#678372: no GSSAPI module for slapd with libsasl2-modules-gssapi-heimdal:amd64
Hi Timm, Please provide the following output: ldd /usr/lib/x86_64-linux-gnu/sasl2/libgssapiv2.so.2.0.25 Do you see any errors listed within /var/log/auth.log when you start slapd? Is your keytab in any location other than /etc/krb5.keytab? If so, what method did you use to specify its location? On 06/21/12 10:27 +0200, Timm Wunderlich wrote: Package: libsasl2-modules-gssapi-heimdal:amd64 Version: 2.1.25.dfsg1-4+b1 With "libsasl2-modules-gssapi-heimdal" i get no GSSAPI module in the supportedSASLMechanisms list from slapd. "libsasl2-modules-gssapi-mit" works fine but i cannot use it since i have a heimdal kdc. What conflict do you have in this scenario? A package dependency issue or some problem with the -mit version talking to a heimdal kdc? Example: $ dpkg -l libsasl2-modules-gssapi-heimdal ii libsasl2-modules-gssapi-heimdal:amd64 2.1.25.dfsg1-4+b1 Pluggable Authentication Modules for SASL (GSSAPI) $ ldapsearch -H ldap://127.0.0.1/ -x -b "" -s base -LLL supportedSASLMechanisms dn: supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: NTLM with "libsasl2-modules-gssapi-mit" i get: $ dpkg -l libsasl2-modules-gssapi-mit ii libsasl2-modules-gssapi-mit:amd64 2.1.25.dfsg1-4+b1 Cyrus SASL - pluggable authentication modules (GSSAPI) $ ldapsearch -H ldap://127.0.0.1/ -x -b "" -s base -LLL supportedSASLMechanisms dn: supportedSASLMechanisms: SCRAM-SHA-1 supportedSASLMechanisms: GS2-IAKERB supportedSASLMechanisms: GS2-KRB5 supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: NTLM I am using Debian GNU/Linux Wheezy AMD64, kernel 3.2.0-2-amd64, slapd 2.4.28-1.1, heimdal kdc 1.6~git20120403+dfsg1-2, all just binaries from Wheezy repo... Regards, Timm Wunderlich -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628237: Bug#628237: OpenLDAP vs. SASL - what happened
On 14/07/11 11:37 -0700, Quanah Gibson-Mount wrote: --On Thursday, July 14, 2011 7:45 PM +0200 Ralph Rößner wrote: Now you could argue that Cyrus upstream should not do that, i.e. breaking the plugin ABI for a "step" release but that argument is two years late (which is how long the .24 has been around). There is no cyrus-sasl 2.1.24 release. There is a release candidate, which when I tested it, had a series of serious flaws. Why anyone would add that to a distribution is beyond me. The latest release of cyrus-sasl is 2.1.23. I find it significant that after 2 years there still remains no official 2.1.24 release after the numerous issue reports that were filtered back to the project. There's been quite a bit of new work even since the 2.1.24rc1 tarball, including work corresponding to the newer IETF SASL standards (GS2, SCRAM, and channel binding), so I wouldn't be surprised to see another version bump before the next release. The package in Debian is actually based on CVS HEAD, and should be in much better shape than 2.1.24rc1 was. Please file any outstanding issues against the sasl packages, and I'll try to filter those to upstream developers as appropriate. -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628237: slapd: installation fails: slap_sasl_init: auxprop add plugin failed
On 22/06/11 14:39 -0400, Patricio Rojo wrote: Hi Dan, Does an upgrade also resolve the trouble for you? If not: No, it was because of upgrading I had the problem. Downgrading was the only solution I found. Maybe this bug should be linked to libsasl2 packages? Except this downgrade, I'm keeping an up-to-date wheezy... Currently, I have the following versions: slapd 2.4.25-1+b1 libsasl2-2 2.1.23.dfsg1-8 libsasl2-modules 2.1.23.dfsg1-8 Do you have any additional log entries in /var/log/auth.log? The problem started as I tried to backup with slapcat. I got: Jun 22 12:30:35 wasabi slapcat: auxpropfunc error version mismatch with plug-in I suspect that the error is being produced due to a version mismatch between the libsasl glue library and the internal (to openldap) slapd auxprop plugin. From a quick glance, these two patches might be at play: openldap-2.4.25/debian/patches/do-not-second-guess-sonames cyrus-sasl2-2.1.24~rc1.dfsg1+cvs2011-05-23/debian/patches/0001_versioned_symbols.diff Then, I tried a restart of /etc/init.d/slapd, which failed. Then, until the fixing downgrade, I got a lot of the following on my auth.log (replacing my true cn by foobar): Jun 22 12:30:45 wasabi nscd: nss_ldap: reconnecting to LDAP server... Jun 22 12:30:45 wasabi nscd: nss_ldap: could not connect to any LDAP server as cn=foo,dc=bar - Can't contact LDAP server Jun 22 12:30:45 wasabi nscd: nss_ldap: failed to bind to LDAP server ldap://localhost/: Can't contact LDAP server Have you customized the sasl-auxprops/olcSaslAuxprops configuration on your server? nop, I haven't touch sasl configuration. In particular, my /etc doesn't have any file with *uxprops* string on it. Also, what contents, if any, do you have in /etc/ldap/sasl2/slapd.conf or /usr/lib/sasl2/slapd.conf? the former is an empty directory, the latter file does not exist in that dir. -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#629589: segfault gone, but problems remain
On 11/06/11 18:45 -0700, Richard A Nelson wrote: On Sat, 11 Jun 2011, Dan White wrote: Yes, interestingly, this shows up for both failure modes: Jun 11 15:37:02 sparks-ave ldapwhoami: canonuserfunc error -7 Jun 11 15:37:02 sparks-ave ldapwhoami: _sasl_plugin_load failed on sasl_canonuser_init for plugin: ldapdb The ldapdb error probably isn't related. You should be able to add: ldapdb_uri: ldapi:/// to /etc/sasl2/slapd.conf or /usr/lib/sasl2/slapd.conf to stop it from complaining. Doesn't help - /etc/sasl2/slapd.conf: allowanonymouslogin: 1 allowplaintext: 1 ldapdb_uri: ldapi:/// I forgot, you'll probably also need a (dummy) ldapdb_canon_attr entry, like: ldapdb_canon_attr: uid -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#629589: segfault gone, but problems remain
On 11/06/11 10:54 -0700, Richard A Nelson wrote: $ ldapwhoami SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context $ ldapwhoami SASL/GSSAPI authentication started SASL username: cowboy@ SASL SSF: 56 SASL data security layer installed. dn:uid=cowboy,ou=users,dc=... $ ldapwhoami SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-1): generic failure: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible. (unknown mech-code 0 for mech unknown) On 11/06/11 15:46:24 -0700, Richard A Nelson wrote: No, 'tis using ldapi:// Yes, interestingly, this shows up for both failure modes: Jun 11 15:37:02 sparks-ave ldapwhoami: canonuserfunc error -7 Jun 11 15:37:02 sparks-ave ldapwhoami: _sasl_plugin_load failed on sasl_canonuser_init for plugin: ldapdb The ldapdb error probably isn't related. You should be able to add: ldapdb_uri: ldapi:/// to /etc/sasl2/slapd.conf or /usr/lib/sasl2/slapd.conf to stop it from complaining. This one for the succes case: Jun 11 15:37:02 sparks-ave ldapwhoami: DIGEST-MD5 common mech free /etc/ldap/ldap.conf: BASEdc=<...> URI ldapi:/// TLS_CACERT /etc/ssl/certs/ca-certificates.crt TLS_CACERTDIR /etc/ssl/certs TLS_CRLCHECK none TLS_REQCERT allow ~/.ldaprc: SASL_MECH gssapi I haven't done gssapi over ldapi:/// before - how does your (client) gssapi mech know which kerberos service ticket to submit to the server (ldap/@REALM) for authentication? Maybe it just uses the local hostname? Does it make any difference if you use ldap://hostname instead? When there's a failure, are you getting the ldap/@REALM service ticket from your kerberos server? Does klist look the same between failures and successes? -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#629589: segfault gone, but problems remain
On 11/06/11 10:54 -0700, Richard A Nelson wrote: $ ldapwhoami SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context $ ldapwhoami SASL/GSSAPI authentication started SASL username: cowboy@ SASL SSF: 56 SASL data security layer installed. dn:uid=cowboy,ou=users,dc=... $ ldapwhoami SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-1): generic failure: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible. (unknown mech-code 0 for mech unknown) Do you have libsasl2-modules-gssapi-mit or libsasl2-modules-gssapi-heimdal installed, and what version? Is your slapd running on a separate host? If so, is it using the same version of libsasl2-modules-gssapi-*? Do you see anything useful in your /var/log/auth.log on the server or client? What kerberos server are you using, and do you see anything in it's syslog output? Would you mind sharing an anonymized copy of your /etc/ldap.conf and ~/.ldaprc? -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628525: libsasl2-modules-gssapi-mit: authentication now fails always
On 02/06/11 21:22 -0500, Dan White wrote: I'm starting to suspect this is a client side problem (with imtest). With the patch below, this command works: cyradm --auth gssapi --tlskey "" imap.example.org but this command still produces the error you're seeing: imtest -m gssapi -t "" imap.example.org I wonder if this might have something to do with changes due to the recent starttls vulnerability. I'll take a closer look. This was also due to a bug in gssapi.c. See: http://bugzilla.cyrusimap.org/bugzilla3/show_bug.cgi?id=3480 The segfaulting problem is fixed for me after applying the patch tied to this bug report: http://bugzilla.cyrusimap.org/bugzilla3/show_bug.cgi?id=3445 -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628525: libsasl2-modules-gssapi-mit: authentication now fails always
On 02/06/11 18:43 +, brian m. carlson wrote: On Tue, May 31, 2011 at 09:13:26AM -0500, Dan White wrote: Do you also receive an error without starttls? I just installed 2.1.24~rc1.dfsg1+cvs2011-05-23-2 and was able to reproduce this error, but only while doing '-t ""', or '-s' (against cyrus imap). I was able to successfully authenticate with: $ imtest -m gssapi imap.example.org Yes, that does seem to work correctly. For me, however, a non-TLS configuration is a non-starter, and anyway, SASL should not act differently over an encrypted connection versus a non-encrypted one. I'm starting to suspect this is a client side problem (with imtest). With the patch below, this command works: cyradm --auth gssapi --tlskey "" imap.example.org but this command still produces the error you're seeing: imtest -m gssapi -t "" imap.example.org I wonder if this might have something to do with changes due to the recent starttls vulnerability. I'll take a closer look. I get a segfault with mutt (with or without -s or -t), so this may actually be two different problems. For both problems, I get the same result regardless of whether I have libsasl2-modules-gssapi-heimdal or libsasl2-modules-gssapi-mit installed. The segfaulting problem is fixed for me after applying the patch tied to this bug report: http://bugzilla.cyrusimap.org/bugzilla3/show_bug.cgi?id=3445 -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628525: libsasl2-modules-gssapi-mit: authentication now fails always
On 29/05/11 19:51 +, brian m. carlson wrote: Package: libsasl2-modules-gssapi-mit Version: 2.1.24~rc1.dfsg1+cvs2011-05-23-2 Severity: grave I use Kerberos 5 for my IMAP and SMTP servers. Previously, everything worked flawlessly. Now, mutt crashes on trying to store a message in the Sent folder, and cyrus-clients-2.4's imtest and smtptest report failure to authenticate with GSSAPI: lakeview ok % imtest -t "" -m GSSAPI -a bmc -u bmc imap.crustytoothpaste.net S: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS LOGINDISABLED AUTH=GSSAPI] Dovecot ready. C: S01 STARTTLS S: S01 OK Begin TLS negotiation now. verify error:num=20:unable to get local issuer certificate verify error:num=27:certificate not trusted verify error:num=21:unable to verify the first certificate TLS connection established: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) C: C01 CAPABILITY S: * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN AUTH=GSSAPI S: C01 OK Pre-login capabilities listed, post-login capabilities have more. C: A01 AUTHENTICATE GSSAPI YIICiwYJKoZIhvcSAQICAQBuggJ6MIICdqADAgEFoQMCAQ6iBwMFAACjggGHYYIBgzCCAX+gAwIBBaEWGxRDUlVTVFlUT09USFBBU1RFLk5FVKIuMCygAwIBA6ElMCMbBGltYXAbG2Nhc3Ryby5jcnVzdHl0b290aHBhc3RlLm5ldKOCAS4wggEqoAMCARKhAwIBA6KCARwEggEY5reXqwcg0WR+ETBz73n1QUtnDTrjSe5vCjmFmk26vFaNU880mW+rcoV4hID9uw6OgTooVQE72qtjeRVhucou5f2Pio5cIJbiHQC6J5vDX8hFwXVT6I7kUJDYxKk35FoO2Ibg48Qr6GWURsuJB5sat8ckKuf4Ak64bCginAO+axm4kwFHHWG+6Kjzdheavd79YpToY5eyY8BoxRcqI3tDIwQOrX1xYK3mQWx38UaVojFDWpy96bpmLARKkxrPrxquzqAlmBTM/mevVMO8QtA6D7zwTSXa69qIi/zrb4c6ooZLtco2VoC996RLxxKWTYHoQGjKDAswkTEG9WqkyJslBap1Xba/s+fs3xQzLrInxLRl+FQTiI4RYqSB1TCB0qADAgESooHKBIHHtDYwVHiLz7F+4HJ+YuBGC+TIbFylSvVX0B8afUMUxyKXYQ4eVu4700nJ5Pj0K3ipY4sZIEZ6TYhSlcMH4TNWwBSb/GV0GM1FC+B9WCwJ0RSEfKf0C49r+De51SUwXPW5rM5aMauKnmbaAiEQ1MCjTnvwTrWHYo/2T21OkouvSrt/2p7aZKaM+P6c5rwVW+DlsGoSooezWVxRvLCf4wArFK2IVbwIsYRXJ38puE2qq8UNyqx1RT6nmM7DUzHfbTATOhQLSdy4nA== S: + C: * Authentication failed. generic failure Security strength factor: 256 A01 BAD Authentication aborted by client. L01 LOGOUT Do you also receive an error without starttls? I just installed 2.1.24~rc1.dfsg1+cvs2011-05-23-2 and was able to reproduce this error, but only while doing '-t ""', or '-s' (against cyrus imap). I was able to successfully authenticate with: $ imtest -m gssapi imap.example.org I get a segfault with mutt (with or without -s or -t), so this may actually be two different problems. For both problems, I get the same result regardless of whether I have libsasl2-modules-gssapi-heimdal or libsasl2-modules-gssapi-mit installed. I'll try to do some more troubleshooting, probably later in the week. -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#624831: cyrus-clients-2.4: with TLS, falsely claims AUTH=GSSAPI not allowed
This was fixed upstream recently. See: http://bugzilla.cyrusimap.org/bugzilla3/show_bug.cgi?id=3444 On 01/05/11 22:27 +, brian m. carlson wrote: Package: cyrus-clients-2.4 Version: 2.4.8-1 Severity: normal File: /usr/bin/imtest I use Kerberos 5 and GSSAPI to authenticate to my IMAP server. If and only if I use TLS, imtest will claim (falsely) that AUTH=GSSAPI was not advertised by the server and refuses to use it to authenticate. Without TLS: lakeview ok % imtest -m gssapi -a bmc -u bmc castro.crustytoothpaste.net S: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS LOGINDISABLED AUTH=GSSAPI] Dovecot ready. With TLS: lakeview ok % imtest -t "" -m gssapi -a bmc -u bmc castro.crustytoothpaste.net S: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS LOGINDISABLED AUTH=GSSAPI] Dovecot ready. C: S01 STARTTLS S: S01 OK Begin TLS negotiation now. verify error:num=18:self signed certificate TLS connection established: TLSv1 with cipher AES256-SHA (256/256 bits) C: C01 CAPABILITY S: * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN AUTH=GSSAPI This was recently fixed in upstream. See: http://bugzilla.cyrusimap.org/bugzilla3/show_bug.cgi?id=3444 -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#624319: slapd: SASL_CONF_PATH environment variable is not respected
On 27/04/11 17:48 +0200, Frank Meisschaert wrote: On 04/27/11 15:30, Dan White wrote: Using the SASL_CONF_PATH environment variable to use different sasl parameters (by using different directories containing a slapd.conf file) for different slapd instances does not work. Same problem for the SASL_PATH environment variable. With regards to SASL_CONF_PATH, see sasl_getconfpath_t(3): sasl_getconfpath_t is used if the application wishes to use a different location for the SASL configuration files. If this callback is not used SASL will either use the location in the environment variable SASL_CONF_PATH (provided we are not SUID or SGID) or /etc/sasl2 by default. Debian slapd includes a patch which defines a SASL_CB_GETCONFPATH callback, which would render SASL_CONF_PATH unused. It appears to set the location to '/usr/lib/sasl2'. Which makes it impossible to run different sasl configurations in different instances on the same host using a different sasl configuration path as is possible with upstream openldap. I know I could use a chroot environment but imho the callback added in debian should somehow have some of the path flexibility as available in upstream. After a closer look at the Debian patch, it actually configures the location to be: /etc/ldap/sasl2:/usr/lib/sasl2 I don't know of a clean way around this problem (other than removing the patch and compiling a local version). I suppose one approach would be to submit a feature request to slapd upstream to make the path configurable. -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#624319: slapd: SASL_CONF_PATH environment variable is not respected
On 27/04/11 14:42 +0200, Frank Meisschaert wrote: Package: slapd Version: 2.4.23-7 Severity: normal Using the SASL_CONF_PATH environment variable to use different sasl parameters (by using different directories containing a slapd.conf file) for different slapd instances does not work. Same problem for the SASL_PATH environment variable. Kind Regards, Frank Meisschaert Frank, With regards to SASL_CONF_PATH, see sasl_getconfpath_t(3): sasl_getconfpath_t is used if the application wishes to use a different location for the SASL configuration files. If this callback is not used SASL will either use the location in the environment variable SASL_CONF_PATH (provided we are not SUID or SGID) or /etc/sasl2 by default. Debian slapd includes a patch which defines a SASL_CB_GETCONFPATH callback, which would render SASL_CONF_PATH unused. It appears to set the location to '/usr/lib/sasl2'. SASL_PATH is documented in: sasl_client_init(3) sasl_getpath_t(3) sasl_server_start(3) and it's purpose is to override the location of the shared library mechanisms, not the config files. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-2-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages slapd depends on: ii adduser 3.112+nmu2 add and remove users and groups ii coreutils 8.5-1 GNU core utilities ii debconf [debconf-2.0] 1.5.38 Debian configuration management sy ii libc6 2.11.2-11 Embedded GNU C Library: Shared lib ii libdb4.8 4.8.30-4 Berkeley v4.8 Database Libraries [ ii libgnutls26 2.10.5-1+b1the GNU TLS library - runtime libr ii libldap-2.4-2 2.4.23-7 OpenLDAP libraries ii libltdl7 2.4-2 A system independent dlopen wrappe ii libperl5.10 5.10.1-19 shared Perl library ii libsasl2-22.1.23.dfsg1-8 Cyrus SASL - authentication abstra ii libslp1 1.2.1-7.8 OpenSLP libraries ii libwrap0 7.6.q-19 Wietse Venema's TCP wrappers libra ii lsb-base 3.2-27 Linux Standard Base 3.2 init scrip ii perl [libmime-base64-perl 5.10.1-19 Larry Wall's Practical Extraction ii psmisc22.13-1utilities that use the proc file s ii unixodbc 2.2.14p2-2 ODBC tools libraries Versions of packages slapd recommends: ii libsasl2-modules 2.1.23.dfsg1-8 Cyrus SASL - pluggable authenticat Versions of packages slapd suggests: ii ldap-utils2.4.23-7 OpenLDAP utilities -- Configuration Files: /etc/default/slapd changed [not included] -- debconf information excluded ___ Pkg-openldap-devel mailing list pkg-openldap-de...@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-openldap-devel -- Dan White BTC Broadband Ph 918.366.0248 (direct) main: (918)366-8000 Fax 918.366.6610email: dwh...@olp.net http://www.btcbroadband.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#622221: Patch to drop libsasl2-modules-otp
On 18/04/11 15:03 +0200, Ondřej Surý wrote: Package: cyrus-sasl2 Severity: normal tags 61 +patch thank you Attached is patch which rip out the otp from cyrus-sasl2. O. Ondřej, Please be aware that if opie isn't present, the otp mechanism should build to use the active auxprop plugin(s) to generate otp challenges (based on the password stored with saslpasswd2). I would recommend testing by simply removing the build dependency on opie, which should do the right thing. If that doesn't work correctly, please let me know and I'll do some testing to figure out why. -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#622221: Please drop libsasl2-modules-otp
On 11/04/11 08:39 +0200, Jan Hauke Rahm wrote: Package: cyrus-sasl2 Version: 2.1.23.dfsg1-8 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, in order to remove opie (see #511582), the otp binary needs to be dropped and the build-dependency on opie be removed. Please do so in your next upload. Thank you! Hauke For what it's worth, I've been using the cyrus otp plugin without opie for a while. If no opie libraries are found during build, otp should build itself to use auxprop as it's token store instead. -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#611674: cyrus-clients-2.4: smtptest falsely claims user is authenticated
On 01/02/11 22:21 -0600, Dan White wrote: On 01/02/11 22:49 -0200, Henrique de Moraes Holschuh wrote: This does not appear to be related specifically to smtptest, but possibly to several of the *test binaries using the imtest.c source. Only if I specify a -m option does the client attempt to authenticate. I've opened bug report 3394 with upstream with a proposed patch. -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#611674: cyrus-clients-2.4: smtptest falsely claims user is authenticated
On 01/02/11 22:49 -0200, Henrique de Moraes Holschuh wrote: On Mon, 31 Jan 2011, brian m. carlson wrote: If I use smtptest with the -a and -u options but without -m, it claims that I am authenticated when I am not. It does not even try to issue an AUTH command. I am certain that bk2...@example.com is not an authorized user at the domain I've specified (since I administer that server). ... S: 220 2.0.0 Ready to start TLS verify error:num=18:self signed certificate TLS connection established: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) C: EHLO smtptest S: 250-castro.crustytoothpaste.net Hello [IPv6:2001:470:1f05:79:216:d3ff:feb3:801e], pleased to meet you S: 250-ENHANCEDSTATUSCODES S: 250-PIPELINING S: 250-EXPN S: 250-VERB S: 250-8BITMIME S: 250-SIZE S: 250-DSN S: 250-ETRN S: 250-AUTH GSSAPI CRAM-MD5 DIGEST-MD5 PLAIN S: 250-DELIVERBY S: 250 HELP Authenticated. Security strength factor: 256 We need the full telemetry to see what SASL is doing. Please run it in verbose mode. If it autenticated through GSSAPI, for example, it might not require a password. Did you, perchance, try to do something that requires one to be authenticated to work? This does not appear to be related specifically to smtptest, but possibly to several of the *test binaries using the imtest.c source. To simplify things, this works like so using 2.2.13: $ smtptest mail.olp.net S: 220 pinky.olp.net ESMTP Postfix (Debian/GNU) C: EHLO example.com S: 250-pinky.olp.net S: 250-PIPELINING S: 250-SIZE 23405714 S: 250-VRFY S: 250-ETRN S: 250-STARTTLS S: 250-AUTH GSSAPI OTP LOGIN PLAIN DIGEST-MD5 CRAM-MD5 S: 250-AUTH=GSSAPI OTP LOGIN PLAIN DIGEST-MD5 CRAM-MD5 S: 250-ENHANCEDSTATUSCODES S: 250-8BITMIME S: 250 DSN C: AUTH DIGEST-MD5 Authentication failed. generic failure and $ lmtptest -p 2004 neo.olp.net S: 220 neo Cyrus LMTP Murder v2.3.12-Debian-2.3.12-1-5 server ready C: LHLO example.com S: 250-neo S: 250-8BITMIME S: 250-ENHANCEDSTATUSCODES S: 250-PIPELINING S: 250-SIZE S: 250-STARTTLS S: 250-AUTH CRAM-MD5 PLAIN GSSAPI OTP DIGEST-MD5 LOGIN S: 250 IGNOREQUOTA C: AUTH DIGEST-MD5 S: 501 5.5.4 undefined error! Authentication failed. generic failure However, using an upstream 2.4.6 installation (not installed from a Debian package): $ smtptest mail.olp.net S: 220 pinky.olp.net ESMTP Postfix (Debian/GNU) C: EHLO smtptest S: 250-pinky.olp.net S: 250-PIPELINING S: 250-SIZE 23405714 S: 250-VRFY S: 250-ETRN S: 250-STARTTLS S: 250-AUTH GSSAPI OTP LOGIN PLAIN DIGEST-MD5 CRAM-MD5 S: 250-AUTH=GSSAPI OTP LOGIN PLAIN DIGEST-MD5 CRAM-MD5 S: 250-ENHANCEDSTATUSCODES S: 250-8BITMIME S: 250 DSN Authenticated. Security strength factor: 0 # lmtptest -p 2004 neo.olp.net S: 220 neo Cyrus LMTP Murder v2.3.12-Debian-2.3.12-1-5 server ready C: LHLO lmtptest S: 250-neo S: 250-8BITMIME S: 250-ENHANCEDSTATUSCODES S: 250-PIPELINING S: 250-SIZE S: 250-STARTTLS S: 250-AUTH CRAM-MD5 PLAIN GSSAPI OTP DIGEST-MD5 LOGIN S: 250 IGNOREQUOTA Authenticated. Security strength factor: 0 Only if I specify a -m option does the client attempt to authenticate. -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#545414: Bug#545414: sudo-ldap: sudo fails with "sudo: setreuid(ROOT_UID, user_uid): Operation not permitted" for ldap users
On 09/12/10 22:37 +0100, Arthur de Jong wrote: On Mon, 2010-12-06 at 23:59 +0800, David Adam wrote: This bit us on trial upgrades to Squeeze, and as this has not yet been fixed I would strongly recommend a section in the release notes on "Possible issues during upgrade" or "Issues to be aware of for squeeze", perhaps along the following lines: Attached is a patch for the release notes on this. I've used David's text as a basis. I've been thinking about encouraging more users to switch to libnss-ldapd. It solves quite a few of the problems in libnss-ldap and is also better maintained. However, since I'm both the Debian maintainer and upstream I'm a bit biased. I'll offer an unbiased +1 for libnss-ldapd. -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#606350: sasl2-bin: "Too many open files" error with PAM - recovery with saslauthd restart
On 08/12/10 15:33 -0400, D G Teed wrote: Here is what one of the directories looked like: ls -l 15950/fd total 0 lrwx-- 1 root root 64 Dec 8 13:52 0 -> /dev/null lrwx-- 1 root root 64 Dec 8 13:52 1 -> /dev/null lrwx-- 1 root root 64 Dec 7 15:47 10 -> socket:[38109596] lrwx-- 1 root root 64 Dec 7 15:47 11 -> socket:[38112677] lrwx-- 1 root root 64 Dec 8 13:52 12 -> socket:[38129166] lrwx-- 1 root root 64 Dec 8 13:52 13 -> socket:[38177341] lrwx-- 1 root root 64 Dec 8 13:52 14 -> socket:[38198508] lrwx-- 1 root root 64 Dec 8 13:52 15 -> socket:[38256709] lrwx-- 1 root root 64 Dec 8 13:52 16 -> socket:[38307912] lrwx-- 1 root root 64 Dec 8 13:52 17 -> socket:[38351349] lrwx-- 1 root root 64 Dec 8 13:52 18 -> socket:[38378460] Try doing a 'netstat -e' and see if you can match some of those sockets up with a connection, and see if you can determine what it's being used for, and what connection state it's in. I'm hoping you can tie the down to a particular type of connection, say, your pam_winbind attempts. If that's the case, then the problem might be due to a bug in that specific pam module, or could be due to a bug in the way saslauthd uses pam. -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#606350: sasl2-bin: "Too many open files" error with PAM - recovery with saslauthd restart
On 08/12/10 09:20 -0400, dteed wrote: This is working fine - users can authenticate against Active Directory when sending email over secure ports 465 and 587 on Postfix. Once every two weeks or so, saslauthd requires a restart to fix a failure to authenticate. Nothing else needs to be touched to remedy the failure. When the failure appears, this is observed in the auth.log: Dec 5 15:45:22 myhostname saslauthd[32586]: PAM unable to dlopen(/lib/security/pam_winbind.so): /lib/security/pam_winbind.so: cannot open shared object file: Too many open files Dec 5 15:45:22 myhostname saslauthd[32586]: PAM adding faulty module: /lib/security/pam_winbind.so Dec 5 15:45:22 myhostname saslauthd[32586]: PAM unable to dlopen(/lib/security/pam_deny.so): /lib/security/pam_deny.so: cannot open shared object file: Too many open files Dec 5 15:45:22 myhostname saslauthd[32586]: PAM adding faulty module: /lib/security/pam_deny.so Dec 5 15:45:22 myhostname saslauthd[32586]: PAM _pam_load_conf_file: unable to open /etc/pam.d/common-auth Dec 5 15:45:22 myhostname saslauthd[32586]: PAM error loading (null) Dec 5 15:45:22 myhostname saslauthd[32586]: PAM _pam_init_handlers: error reading /etc/pam.d/other Dec 5 15:45:22 myhostname saslauthd[32586]: PAM _pam_init_handlers: [Critical error - immediate abort] Dec 5 15:45:22 myhostname saslauthd[32586]: PAM error reading PAM configuration file Dec 5 15:45:22 myhostname saslauthd[32586]: PAM pam_start: failed to initialize handlers Dec 5 15:45:22 myhostname saslauthd[32586]: DEBUG: auth_pam: pam_start failed: Critical error - immediate abort Dec 5 15:45:22 myhostname saslauthd[32586]: do_auth : auth failure: [user=dteed] [service=smtp] [realm=] [mech=pam] [reason=PAM start error] Dec 5 15:45:32 myhostname saslauthd[32586]: server_exit : master exited: 32586 Dec 5 15:45:32 myhostname saslauthd[1696]: detach_tty : master pid is: 1696 Dec 5 15:45:32 myhostname saslauthd[1696]: ipc_init : listening on socket: /var/run/saslauthd/mux I'd guess that would be caused by a file descriptor leak, either in saslauthd itself or in one of your PAM modules. Can you monitor /proc//fd/ to see if you can find out what type of file descriptors are being left open? -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#590598: saslauthd - auth via ldap/sasl logs debug messages
On 28/07/10 16:07 +0200, Bastian Blank wrote: On Wed, Jul 28, 2010 at 08:24:51AM -0500, Dan White wrote: On 28/07/10 10:28 +0200, Bastian Blank wrote: No. The tools must not send debug messages without being asked to do so. Why does libsasl use syslog for interactive usage anyway? It's a design philosophy of how libsasl attempts to perform debugging since, in many cases, it's the only way (via syslog) that it can provide feedback to the user or system administrator. This is no "feedback", because I didn't ask for it. This is a DoS against the system via syslog. If you think this output is important, please describe what a normal user can read out of it, especially as there is no surrounding information. This philosophy is briefly discussed in: http://cyrusimap.web.cmu.edu/imapd/install-configure.html Where is this documented _in_ the Debian package that the user must change the default syslog config? It is quite tersely documented in upstream within the doc/sysadmin.html, but there is no mention in the Debian README. -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#590598: saslauthd - auth via ldap/sasl logs debug messages
On 28/07/10 10:28 +0200, Bastian Blank wrote: On Wed, Jul 28, 2010 at 12:56:40AM -0500, Dan White wrote: On 27/07/10 21:59 +0200, Bastian Blank wrote: It's because of the 'auth,authpriv.*' line in rsyslogd.conf (it also exists the same way in the sysklogd package). Yes, this is the correct default. The debug statements also happen when bypassing saslauthd: ldapwhoami -H ldap://192.0.2.1 -U jsmith -Y DIGEST-MD5 or using imtest. So libsasl reports debug messages to syslog. Correct. To drop the messages from syslog, replace that line with: auth,authpriv.info /var/log/auth.log or some other lower priority level. No. The tools must not send debug messages without being asked to do so. Why does libsasl use syslog for interactive usage anyway? It's a design philosophy of how libsasl attempts to perform debugging since, in many cases, it's the only way (via syslog) that it can provide feedback to the user or system administrator. This philosophy is briefly discussed in: http://cyrusimap.web.cmu.edu/imapd/install-configure.html -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#590598: saslauthd - auth via ldap/sasl logs debug messages
On 27/07/10 21:59 +0200, Bastian Blank wrote: On Tue, Jul 27, 2010 at 02:08:00PM -0500, Dan White wrote: What are the contents of your /etc/default/saslauthd and /etc/saslauthd.conf? What's the output of 'grep -r auth /etc/*syslog*? | # grep -v "^#" /etc/default/saslauthd | grep -v "^$" | START=yes | DESC="SASL Authentication Daemon" | NAME="saslauthd" | MECHANISMS="ldap" | MECH_OPTIONS="" | THREADS=5 | OPTIONS="-c -m /var/run/saslauthd" | # cat /etc/saslauthd.conf | ldap_servers: ldap://ldap.example.org | ldap_use_sasl: yes | ldap_mech: DIGEST-MD5 | # grep -r auth /etc/*syslog* | /etc/rsyslog.conf:auth,authpriv.* /var/log/auth.log | /etc/rsyslog.conf:*.*;auth,authpriv.none-/var/log/syslog | /etc/rsyslog.conf: auth,authpriv.none;\ | /etc/rsyslog.conf: auth,authpriv.none;\ I get the same results, with a similar configuration. It's because of the 'auth,authpriv.*' line in rsyslogd.conf (it also exists the same way in the sysklogd package). The debug statements also happen when bypassing saslauthd: ldapwhoami -H ldap://192.0.2.1 -U jsmith -Y DIGEST-MD5 or using imtest. To drop the messages from syslog, replace that line with: auth,authpriv.info /var/log/auth.log or some other lower priority level. -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#590598: saslauthd - auth via ldap/sasl logs debug messages
On 27/07/10 19:45 +0200, Bastian Blank wrote: Package: sasl2-bin Version: 2.1.23.dfsg1-5 saslauthd with ldap/sasl authentication logs sasl debugging output to syslog. | saslauthd[13685]: DIGEST-MD5 client step 2 | saslauthd[13685]: DIGEST-MD5 client step 2 | saslauthd[13685]: Authentication failed for root: Bind to ldap server failed (invalid user/password or insufficient access) (-7) | saslauthd[13685]: do_auth : auth failure: [user=root] [service=ldap] [realm=] [mech=ldap] [reason=Unknown] The first two DIGEST-MD5 messages are debugging output of the digestmd5 auth plugin. What are the contents of your /etc/default/saslauthd and /etc/saslauthd.conf? What's the output of 'grep -r auth /etc/*syslog*? -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578434: cyrus: Changing Junk-Status to No-Junk (in Icedove3) let disappear mail and create hardlink
On 20/04/10 15:06 +0200, Jakobus Schuerz wrote:
Thank you for this hint.
Here the Logging:
This happened, when i set the Junkstate in "No-Junk" in the Junk-directory.
<1271768571
1271768571>267 OK Completed
<1271768571<268 uid store 8357 +FLAGS (NonJunk)
1271768571>* 2 FETCH (FLAGS (\Recent \Seen Junk NonJunk) UID 8357)
268 OK Completed
<1271768571<269 uid store 8357 -FLAGS (Junk)
1271768571>* 2 FETCH (FLAGS (\Recent \Seen NonJunk) UID 8357)
269 OK Completed
<1271768571<270 uid store 8357 -Flags (\Seen)
1271768571>* 2 FETCH (FLAGS (\Recent NonJunk) UID 8357)
270 OK Completed
<1271768571<271 IDLE
1271768571>+ idling
<1271768571
1271768571>271 OK Completed
<1271768571<273 uid copy 8357 "INBOX"
1271768571>273 OK [COPYUID 1256304629 8357 27209] Completed
Copied to the INBOX, which should utilize a hard link if Cyrus determines
that it can. Those details should be hidden from the client though.
<1271768571<274 uid store 8357 +FLAGS (\Deleted \Seen)
1271768571>* 2 FETCH (FLAGS (\Recent \Deleted \Seen NonJunk) UID 8357)
274 OK Completed
Marked for deletion.
<1271768571<275 noop
1271768571>275 OK Completed
<1271768571<276 getquotaroot "INBOX/Junk"
1271768571>* QUOTAROOT INBOX/Junk
276 OK Completed
<1271768571<277 UID fetch 8358:* (FLAGS)
1271768571>* 2 FETCH (FLAGS (\Recent \Deleted \Seen NonJunk) UID 8357)
277 OK Completed (0.000 sec)
<1271768571<278 IDLE
1271768571>+ idling
Closing the No-Junk mailbox should implicitly expunge the message (in the
No-Junk mailbox).
This happened, when i changed into the INBOX, while the Mail disappears:
==> 20098 <==
<1271768603
1271768603>* 1051 EXISTS
* 7 RECENT
140 OK Completed
<1271768603<141 noop
1271768603>141 OK Completed
<1271768603<142 getquotaroot "INBOX"
1271768603>* QUOTAROOT INBOX
142 OK Completed
<1271768603<143 UID fetch 27209:* (FLAGS)
1271768603>* 1051 FETCH (FLAGS (\Recent NonJunk) UID 27209)
143 OK Completed (0.000 sec)
There is probably some kind of caching involved here. Your client
is searching for any messages with UID 27209 or greater, and finds the new
message with that UID.
<1271768603<144 UID fetch 27209 (UID RFC822.SIZE FLAGS
BODY.PEEK[HEADER.FIELDS (From To Cc Bcc Subject Date Message-ID Priority
X-Priority References Newsgroups In-Reply-To Content-Type x-spam-status
x-spam-flag content-type x-bogosity)])
1271768603>* 1051 FETCH (FLAGS (\Recent NonJunk) UID 27209 RFC822.SIZE
1913 BODY[HEADER.FIELDS (From To Cc Bcc Subject Date Message-ID Priority
X-Priority References Newsgroups In-Reply-To Content-Type x-spam-status
x-spam-flag content-type x-bogosity)] {321}
Date: Sat, 7 Mar 2009 01:47:16 +0100
From: Jakobus =?UTF-8?B?U2Now7xyeg==?=
To: jakob.schu...@gmx.at, Jakobus =?UTF-8?B?U2Now7xyeg==?= (ICH)
Subject: Neuer Server TEST
Message-ID: <20090307014716.2d595...@gmx.at>
Content-Type: text/plain; charset=US-ASCII
)
144 OK Completed (0.000 sec)
<1271768604<145 uid store 27209 +Flags (\Seen \Deleted)
1271768604>* 1051 FETCH (FLAGS (\Recent \Deleted \Seen NonJunk) UID 27209)
145 OK Completed
The client marks the message for deletion, but I don't think it should be
from your stated expectation.
<1271768604<146 IDLE
1271768604>+ idling
And when you close the INBOX, the message should be unlinked or removed
as it's expunged.
--
Dan White
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578434: cyrus: Changing Junk-Status to No-Junk (in Icedove3) let disappear mail and create hardlink
On 19/04/10 23:18 +0200, Jakob Schuerz wrote: Package: cyrus-imapd-2.2 Version: 2.2.13-19 Severity: important File: cyrus When i mark an Mail in Icedove in the Junk-Folder as "no-Junk", it goes to the Inbox-Folder as unread. When i change to the Inbox-Folder, the Mail sometimes disapperas immediately. Never found it again in Icedove. So. I use Icedove as a IMAP-Client for a cyrus-Mailserver. Cyrus runs on the same machine (localhost). When i look in the spool-directory of cyrus /var/spool/cyrus/mail/j/user/jakob i can find the expecting mail with grep. This mail/the file is now hardlinked for example: -rw--- 3 cyrus mail 15310 12. Apr 22:37 27183. Hard links are indicative of 'singleinstancestore' being enabled (which is on by default). See imapd.conf(5). To trouble shoot why your messages are disappearing, reference /usr/share/doc/cyrus-imapd-2.2/README.Debian.debug.gz and enable telemetry logging. -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#551923: mailbox rename fails with special user names
On 23/01/10 16:26 +0100, Christoph Berg wrote: On 2.3.16, I get: zek.olp.net> create user/test zek.olp.net> rename user/test user/test2 zek.olp.net> create user/cyrus.test zek.olp.net> rename user/cyrus.test user/test.cyrus renamemailbox: Permission denied zek.olp.net> setacl user/cyrus.test cyrus all zek.olp.net> rename user/cyrus.test user/test.cyrus renamemailbox: System I/O error I'll take a closer look at why. I'm reassigning this bug to cyrus-imapd-2.3 so we can track the problem there. I didn't nail down this bug, but the issue seems to be related to the fact that it's an administrator's mailbox (cyrus). -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#471563: After the first 'id' command is issues Cyrus IMAPD always returns an error
On 17/01/10 17:35 -0600, Dan White wrote: I agree. The server should be sending a NIL/OK. According to http://www.rfc-editor.org/rfcxx00.html, 2971 is still current. I'll work on a bug report for upstream and see how difficult it'll be to patch existing behavior. I've opened a bug upstream, with a proposed patch: https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3189 -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#471563: After the first 'id' command is issues Cyrus IMAPD always returns an error
On 17/01/10 21:53 +0100, Sergio Gelato wrote:
* Dan White [2010-01-16 21:58:33 -0600]:
a1 id ("vendor" "Zimbra" "os" "Linux" "os-version" "12")
* ID ("name" "Cyrus IMAPD" "version" "v2.2.13-Debian-2.2.13-10 2006/11/13 16:17:53" "vendor" "Project Cyrus" "support-url"
"http://asg.web.cmu.edu/cyrus"; "os" "Linux" "os-version" "2.6.18-ovz-028stab051.1" "environment" "Built w/ Cyrus SASL 2.1.22; Running w/Cyrus SASL 2.1.22;
Built w/Sleepycat Software: Berkeley DB 4.2.52: (December 3, 2003); Running w/Sleepycat Software: Berkeley DB 4.2.52: (December 3, 2003); Built w/OpenSSL 0.9.8c 05 Sep 2006; Running w/ OpenSSL 0.9.8c 05 Sep 2006; CMU
Sieve 2.2; TCP Wrappers; NET-SNMP; mmap = shared; lock = fcntl; nonblock = fcntl; idle = poll")
a1 OK Completed
a2 id ("vendor" "zimbra")
a2 NO Only one Id allowed in non-authenticated state
I don't see NO listed as a valid response in RFC 2971 § 3.1, only OK and BAD.
So it would seem that this behavior is not RFC-compliant.
I agree. The server should be sending a NIL/OK.
According to http://www.rfc-editor.org/rfcxx00.html, 2971 is still current.
I'll work on a bug report for upstream and see how difficult it'll be to
patch existing behavior.
--
Dan White
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#551923: mailbox rename fails with special user names
On 17/01/10 10:38 +0100, Alessandro Polverini wrote: Dan White wrote: [...] This does not work for any top-level mailboxes. The dot in the above (in the case where unixhierarchysep is set to yes) is not relevant: zek.olp.net> cm user/test zek.olp.net> setacl user/test cyrus all zek.olp.net> rename user/test user/test2 renamemailbox: Operation is not supported on mailbox If this helps on my setup (cyrus 2.2.13) I can rename mailboxes just fine: localhost> cm user/test1 localhost> rename user/test1 user/test2 localhost> I have unixhierarchysep is set to yes. Alex Alex, You are absolutely right. I missed the imapd.conf option 'allowusermoves: 1'. Do you have that set? With that option set, I can move top level user mailboxes: zek.olp.net> create user/test zek.olp.net> rename user/test user/test2 zek.olp.net> create user/cyrus.test zek.olp.net> rename user/cyrus.test user/test.cyrus renamemailbox: Permission denied zek.olp.net> setacl user/cyrus.test cyrus all zek.olp.net> rename user/cyrus.test user/test.cyrus zek.olp.net> lm user/cyrus.test (\HasNoChildren) user/dwhite/test (\HasNoChildren) user/dwhite (\HasChildren) user/test.cyrus (\HasNoChildren) user/dwhite/spam (\HasNoChildren) user/test2 (\HasNoChildren) So I'm able to move toplevel mailboxes with the allowusermoves set to one, but I'm not allowed to move the (presumably) top level mailbox of user/cyrus.test until I give the cyrus user permissions on it. On 2.3.16, I get: zek.olp.net> create user/test zek.olp.net> rename user/test user/test2 zek.olp.net> create user/cyrus.test zek.olp.net> rename user/cyrus.test user/test.cyrus renamemailbox: Permission denied zek.olp.net> setacl user/cyrus.test cyrus all zek.olp.net> rename user/cyrus.test user/test.cyrus renamemailbox: System I/O error I'll take a closer look at why. -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#551923: mailbox rename fails with special user names
On 17/01/10 00:06 -0600, Dan White wrote: zek.olp.net> create user/cyrus.test zek.olp.net> setacl user/cyrus.test cyrus all zek.olp.net> rename user/cyrus.test user/test.cyrus renamemailbox: Operation is not supported on mailbox zek.olp.net> This does not work for any top-level mailboxes. The dot in the above (in the case where unixhierarchysep is set to yes) is not relevant: zek.olp.net> cm user/test zek.olp.net> setacl user/test cyrus all zek.olp.net> rename user/test user/test2 renamemailbox: Operation is not supported on mailbox -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#551923: mailbox rename fails with special user names
Package: cyrus-imapd-2.2 Version: 2.2.13-14+lenny3 Severity: normal File: cyrus-imapd # cyradm -u cyrus -w 123 localhost localhost> create user/cyrus.test localhost> rename user/cyrus.test user/test.cyrus renamemailbox: Permission denied localhost> create user/test.cyrus localhost> quit It is possible to create a mailbox user/test.cyrus. Consequently it should be possible to rename user/cyrus.test to user/test.cyrus. The 'Permission denied' error is due to incorrect permissions: zek.olp.net> create user/cyrus.test zek.olp.net> setacl user/cyrus.test cyrus all zek.olp.net> rename user/cyrus.test user/test.cyrus renamemailbox: Operation is not supported on mailbox zek.olp.net> After some searching, I found that renaming top-level (user) mailboxes is not yet supported by upstream: http://cyrusimap.web.cmu.edu/imapd/bugs.html and here: http://oreilly.com/catalog/mimap/chapter/ch09.html I confirmed this still occurs on the latest upstream release (2.3.16). -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#535164: squat assertion failed
Package: cyrus-imapd-2.2 Version: 2.2.13-10 Severity: normal Hi, running squatter on a specific user's folder i get the following error : Indexing mailbox user/... fatal error: Internal error: assertion failed: squat_internal.c: 161: v64 >= 0 after which squatter dies.I tried reconstructing the folder, but it hasnt made a difference. Since squatter terminates on this folder, i can't get squatter to process everything. Gloria, Removing the squat file (cyrus.squat) for the user may be necessary to recover, if cyrreconstruct does not. Were you able to recover from this error back in June? Have you encountered it again? -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#482642: "cyrdeliver" command is ignoring the mailbox parameter (-m) and is delivering messages to INBOX.
Package: cyrus-imapd-2.2 Version: 2.2.13-14 Severity: normal I am trying to use spamassassin in a Postfix + Cyrus environment, using user preferences. I did a custom mail transport command written in PHP. It calls "spamc" using recipient's name and if "spamd" classifies input message as spam, my script calls "cyrdeliver -m INBOX.spam ". I think this is a better solution than Sieve, because users don't need to learn Sieve and create a script in order do transfer unsolicited messages to a "spam" folder. But I don't know why "cyrdeliver" ignores the "-m" parameter and always delivers unsolicited messages to INBOX. This behavior occurs either with or without an existing "INBOX.spam" folder in user mailbox. "cyrdeliver" man page says I could do it... I successfully delivered to a submailbox on 2.2.13-17 like so: ~$ cat /tmp/email | /usr/sbin/cyrdeliver -m 'spam' dwhite which placed the email into user.dwhite.spam. I also had to set an ACL for 'anyone p', as discussed in the manpage. specifying '-m INBOX.spam' appears to be treated as a typo, and places the message into the user's INBOX (user.dwhite). specifying '-m spam', but without having an ACL of 'anyone p' also delivered the message to my INBOX rather than INBOX.spam. This seems to be consistent with the existing man page for cyrdeliver. -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#471563: After the first 'id' command is issues Cyrus IMAPD always returns an error
Package: cyrus-imapd-2.2
Version: 2.2.13-10
Severity: important
I was testing the Zimbra Desktop IMAP client against my Cyrus server and
found what I thought to be a bug in that client. On further
investigation I believe this is a bug in the Cyrus IMAPD component; the
following is from the original bug:
] nc rimspace.net 143
* OK anu Cyrus IMAP4 v2.2.13-Debian-2.2.13-10 server ready
a0 capability
* CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS NAMESPACE
UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT
THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE IDLE STARTTLS
a0 OK Completed
a1 id ("vendor" "Zimbra" "os" "Linux" "os-version" "12")
* ID ("name" "Cyrus IMAPD" "version" "v2.2.13-Debian-2.2.13-10 2006/11/13 16:17:53" "vendor" "Project Cyrus" "support-url"
"http://asg.web.cmu.edu/cyrus"; "os" "Linux" "os-version" "2.6.18-ovz-028stab051.1" "environment" "Built w/ Cyrus SASL 2.1.22; Running w/Cyrus SASL 2.1.22;
Built w/Sleepycat Software: Berkeley DB 4.2.52: (December 3, 2003); Running w/Sleepycat Software: Berkeley DB 4.2.52: (December 3, 2003); Built w/OpenSSL 0.9.8c 05 Sep 2006; Running w/ OpenSSL 0.9.8c 05 Sep 2006; CMU
Sieve 2.2; TCP Wrappers; NET-SNMP; mmap = shared; lock = fcntl; nonblock = fcntl; idle = poll")
a1 OK Completed
a2 id ("vendor" "zimbra")
a2 NO Only one Id allowed in non-authenticated state
a3 logout
* BYE LOGOUT received
a3 OK Completed
] nc rimspace.net 143
* OK anu Cyrus IMAP4 v2.2.13-Debian-2.2.13-10 server ready
a4 id ("vendor" "zimbra")
a4 NO Only one Id allowed in non-authenticated state
a5 logout
* BYE LOGOUT received
a5 OK Completed
So, it looks like /any/ id command after the first returns the same state.
How about this...
] nc rimspace.net 143
* OK anu Cyrus IMAP4 v2.2.13-Debian-2.2.13-10 server ready
a0 login daniel "XX"
a0 OK User logged in
a1 logout
* BYE LOGOUT received
a1 OK Completed
] nc rimspace.net 143
* OK anu Cyrus IMAP4 v2.2.13-Debian-2.2.13-10 server ready
a0 id ("vendor" "Zimbra")
a0 NO Only one Id allowed in non-authenticated state
a1 logout
* BYE LOGOUT received
a1 OK Completed
...which makes it look like an upstream bug in Cyrus IMAP where any ID
command will result in that error to any subsequent ID command or, at least,
where
that happens iff you don't authenticate correctly the first time.
While the Zimbra client should probably cope with the failure of the id
command it is not reasonable, I think, that any user can cause ID
commands to fail globally for all other users.
I confirmed that this happens with 2.2.13-17, and also with an undebianized
2.3.16.
The issue is that if subsequent connections come in to the same imapd
process and no other users have authenticated against that imapd process,
then subsequent ID commands will receive the 'NO Only one Id allowed in
non-authenticated state' error, until either a new imapd process is fired
up, or until an authentication happens.
The ID command is governed by RFC 2971, which states:
7. Security Considerations
...
Since this command includes arbitrary data and does not require the
user to authenticate, server implementations are cautioned to guard
against an attacker sending arbitrary garbage data in order to fill
up the ID log. In particular, if a server naively logs each ID
command to disk without inspecting it, an attacker can simply fire up
thousands of connections and send a few kilobytes of random data.
Servers have to guard against this. Methods include truncating
abnormally large responses; collating responses by storing only a
single copy, then keeping a counter of the number of times that
response has been seen; keeping only particularly interesting parts
of responses; and only logging responses of users who actually log
in.
This 'functionality' may be Cyrus's way of circumventing a denial of
service attack by a string of unauthenticated users.
--
Dan White
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#559923: avelsieve: Default configuration should specify Sieve port 4190
Package: avelsieve Version: 1.9.7-6+lenny1 Severity: normal Tags: patch See Bug#555664 for reference. IANA has assigned port 4190 to the Managesieve protocol, and package netbase has included the new default. The default Avelsieve configuration specifies port 2000, and should be changed. See below for a trivial patch to update the port: --- avelsieve-config.php.old2009-12-07 14:06:12.0 -0600 +++ avelsieve-config.php2009-12-07 14:11:46.0 -0600 @@ -35,10 +35,14 @@ /* === ManageSieve Backend Options */ /* */ -/* Port where timsieved listens on the Cyrus IMAP server. Default is 2000. */ +/** + * Port where timsieved listens on the Cyrus IMAP server. Default is 4190; + * However, port 2000 was commonly used before the ManageSieve protocol was + * officially assigned a port by IANA. + */ global $sieveport; -$sieveport = 2000; +$sieveport = 4190; /** * @var string Space separated list of preferred SASL mechanisms for the -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-xen-686 (SMP w/1 CPU core) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages avelsieve depends on: ii debconf1.5.24Debian configuration management sy ii squirrelmail 2:1.4.15-4+lenny2 Webmail for nuts avelsieve recommends no packages. Versions of packages avelsieve suggests: pn cyrus-imapd-2.2 | dovecot-ima (no description available) -- debconf information: * avelsieve/runconfig: true avelsieve/no_purge: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#555664: closed by Marco d'Itri (Bug#555664: fixed in netbase 4.38)
On 07/12/09 15:37 -0200, Henrique de Moraes Holschuh wrote: On Mon, 07 Dec 2009, Klaus Ethgen wrote: On Sun, Dec 06, 2009 at 05:57:10PM +, Debian Bug Tracking System wrote: >* etc-services: added sieve (4190/tcp). >* etc-services: removed sieve (2000/tcp). (Closes: #555664) Uh, that's a very bad idea! managesieve is using port 2000 for long time now. To change it in service file ends in clients not able anymore to http://www.iana.org/assignments/port-numbers And you *are* free to tell cyrmaster to listen to port 2000, you know. Out of curiosity, I just tried to do a: $sieveport = 'sieve'; instead of $sieveport = 2000; in my PHP Avelsieve config, but no go. PHP, or Avelsieve, will not do service name resolution like Cyrus, unfortunately. -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#558014: sasl2-bin: doesn't return from /etc/init.d/saslauthd start -> postinst script hangs
On 25/11/09 23:02 +0100, Dirk Dike wrote: Package: sasl2-bin Version: 2.1.22.dfsg1-8+etch1 Severity: critical Justification: breaks unrelated software # /etc/init.d/saslauthd start saslauthd[28763] :main: num_procs : 5 saslauthd[28763] :main: mech_option: NULL saslauthd[28763] :main: run_path : /var/run/saslauthd saslauthd[28763] :main: auth_mech : kerberos5 Have you customized your /etc/default/saslauthd? It appears that saslauthd is attempting to use the kerberos5 mech, which may in turn be hanging on a call to a kerberos library. -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#555664: Port conflict between asterisk and cyrus-common
On 20/11/09 23:57 -0200, Henrique de Moraes Holschuh wrote: On Sat, 14 Nov 2009, Faidon Liambotis wrote: [ besides being a standard-body assigned port, that port is used by all the Cisco phones out there that speak SCCP. ] Reassigning to cyrus-common. We are explicitly forbidden by RFC to listen on ANY "lmtp" port by default, and Debian should not ship anything called lmtp in /etc/services for the same reason. Are we doing that in the packages? No, I don't believe so. I just installed cyrus-common-2.2 (which contains lmtpd) version 2.2.13-17, and I do not have an lmtp entry in /etc/services. The default /etc/cyrus.conf shipped only include an lmtpunix service and does not attempt to listen on inet port lmtp. I've always manually added lmtp/csync/mupdate to /etc/services. -- Dan White -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#532556: cyrus-sasl2: "you must install some of the modules" -> Depends
Steve Langasek wrote: How does this show anything other than that most users have left the sasl library in an unusable state on their systems? libsasl2-2 does contain the EXTERNAL mech, and the sasldb auxprop plugin (I believe). The following common packages contain dependencies on libsasl2 but function just fine without having any additional authentication mechs: postfix libldap2/ldap-utils/slapd mutt subversion asterisk Adding additional dependencies will only add cruft to many of these users during their next upgrade. - Dan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#532556: cyrus-sasl2: "you must install some of the modules" -> Depends
Steve Langasek wrote:
Hi folks,
The libsasl2-2 package states quite explicitly that:
If you intend to use this package on a server that provides SASL
authentication, then you must install some of the libsasl2-modules*
packages.
This suggests that the modules should actually be dependencies of the
package rather than merely recommends, which is what the Ubuntu package
currently does as a result. Here is a patch that implements this:
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}, libsasl2-modules (= ${Source-Version}) |
libsasl2-modules-sql (= ${Source-Version}) | libsasl2-modules-gssapi-heimdal (=
${Source-Version}) | libsasl2-modules-kerberos-heimdal (= ${Source-Version}),
${misc:Depends}
Conflicts: postfix (<< 2.3.4-3), libsasl2-gssapi-mit (<< 2.1.22), libsasl2-krb4-mit
(<< 2.1.22)
-Recommends: libsasl2-modules (= ${binary:Version})
See: http://qa.debian.org/popcon.php?package=cyrus-sasl2
Summary:
libsasl2-2 install base: 98.94%
libsasl2-modules install base: 54.72%
libsasl2-modules-sql install base: 1.17%
Personally speaking (I'm not a package maintainer), I think these
dependencies should belong in the packages that use them (such as
cyrus-imapd). libsasl2-2 itself should keep it's dependencies small.
The gssapi and sql packages have a fair amount of 3rd party dependencies
that many admins probably won't ever need.
- Dan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#433715: Patch also waiting in Bugzilla for upstream
Thanks Torsten, I'd like to go ahead and close this bug here, and defer to the upstream patch request. I'm successfully using this patch myself. I had mentioned at one time I had problems using it with cyrus pop3d, but that was due to a bug in pop3d itself, and fixed in cyrus bug# 2996. I've also submitted a patch for Howard to look at that performs a Password EXOP if the userPassword attribute gets written back to the sasl_store via ldapdb, such as during a saslpasswd2 command, or when auto_transition is enabled. He was going to do some cleanup on it and I'm expecting he'll pass it on to upstream at some point. - Dan Torsten Schlabach wrote: Hi! Just FYI: The canon_user patch is waiting on the Bugzilla for the upstream of the Cyrus SASL lib as well, but just as of early this week: https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3031 Howard Chu had developed this month back and Dan White and myself had been using it any both forget to worry about getting the code committed. It seems though that the Cyrus SASL people aren't watching their Bugzilla and mailing list that much these days. Regards, Torsten ___ Pkg-cyrus-sasl2-debian-devel mailing list [EMAIL PROTECTED] http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-sasl2-debian-devel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405495: libsasl2-modules-ldap: libldapdb segfaults
Torsten Schlabach wrote: Fabian Fagerholm wrote: we need help from someone who can (has the ability to, and has the time to) read the code and figure out what's happening here. I decided to start investigating this, especially as the problem gets worse with Exim -> Cyrus SASL -> ldapdb. Other then with that Cyrus IMAPd -> Cyrus SASL -> ldapdb setup, the workaround to use a mechanism != DIGEST-MD5 between the ldapdb auxprop plugin and the LDAP server does NOT work. It will make sense to keep the people who make the SASL lib in the loop: https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3032 My current state of investigation is there as well. Unfortunately, not a lot yet. Regards, Torsten I've ran into SASL reentrant problems similar to this using the GSSAPI mechanism from within ldapdb. In my case, it appeared to be a problem in the openldap 2.1 sasl code. After recompiling my ldapdb plugin using a more recent openldap 2.3 library my segfaults went away. - Dan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#455983: libsasl2-modules-gssapi-heimdal: SASL<->SASL GSSAPI failure (likely in -mit version as well)
Richard A Nelson wrote: On Wed, 12 Dec 2007, Richard A Nelson wrote: /etc/mail/authinfo: AuthInfo: "U:?" "P:?" "R:" "M:GSSAPI" With that format of entry, the odd error is gone: GSSAPI Error: An unsupported mechanism was requested (unknown mech-code 0 for mech unknown) But smtptest still shows: S: 535 5.7.0 authentication failed Richard, Does /var/log/auth.log give you any helpful information? - Dan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#455983: libsasl2-modules-gssapi-heimdal: SASL<->SASL GSSAPI failure (likely in -mit version as well)
Richard,
The cyrus-sasl list might also be a good resource for this question.
You can try 'saslpluginviewer' to make sure that the GSSAPI
mechanism is installed.
You can also try 'smtptest', from the cyrus-clients-2.x package,
for a second opinion.
Also, might not be a bad idea to try the
libsasl2-modules-gssapi-mit package to see if you get the same error.
- Dan
Richard A Nelson wrote:
Package: libsasl2-modules-gssapi-heimdal
Version: 2.1.22.dfsg1-16
Severity: normal
I'm using SASL with OpenLDAP, Sendmail, and a few other packages
For imap/pop, I use Dovecot - with its own SASL implimentation
In the quest to simplify and improve my infrastructure at home and work,
I've recently added Kerberos (Heimdal) to the mix (What was I thinking).
GSSAPI auth is working with SSH, OpenLDAP, Dovecot, apache2(mod-auth-kerb)
just fine.
The only failing case I have is sendmail -> sendmail AUTH GSSAPI; where
I always get this error on the client:
050 >>> AUTH GSSAPI
YIICjgYJKoZIhvcSAQICAQBuggJ9MIICeaADAgEFoQMCAQ6iBwMFACCj
050 535 5.7.0 authentication failed
050 >>> AUTH DIGEST-MD5
050 334
bm9uY2U9IjNRcHpBMnRIbDMzSzFqN3JCeHdsUmdUbkhyWlEwTnhoL2ZVbFFRb1BHYkk9Iixy
050 >>>
050 235 2.0.0 OK Authenticated
And this on the server side:
sendmail[9310]: GSSAPI Error: An unsupported mechanism was requested
(unknown mech-code 0 for mech unknown)
/usr/lib/sasl2/Sendmail.conf contains:
log_level: # doesn't seem to do much :(
keytab: /etc/mail/sendmail.keytab # Is actually accessed
mech_list: EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 NTLM LOGIN PLAIN
pwcheck_method: auxprop # Needed until GSSAPI is working
auxprop_plugin: ldapdb
ldapdb_uri: ldapi://
... ldap specs ...
The client is using the following to authenticate (/etc/mail/authinfo):
AuthInfo: "U:sendmail" "I:sendmail" "P:" "R:" "M:GSSAPI
DIGEST-MD5 CRAM-MD5 LOGIN PLAIN"
For testing, I'm running sendmail in standalone mode, and have
initialized my cc with the smtp/fqdn principle:
# klist -v
Credentials cache: FILE:/tmp/krb5cc_0
Principal: smtp/@
Cache version: 4
Server: krbtgt/@
Client: smtp/@
Ticket etype: aes256-cts-hmac-sha1-96, kvno 1
Ticket length: 362
Auth time: Dec 12 17:01:07 2007
End time: Dec 26 17:01:02 2007
Renew till: Dec 26 17:01:02 2007
Ticket flags: forwardable, renewable, initial, pre-authenticated
Addresses: addressless
Running strace -f sendmail -bD -X smlog >log 2>&1 shows, amongs other
things:
[pid 9310] open("/etc/mail/sendmail.keytab", O_RDONLY) = 13
... seek/read
[pid 9310] open("/etc/krb5.conf", O_RDONLY) = 13
... read
[pid 9310] uname({sys="Linux", node="", ...}) = 0
...
[pid 9310] open("/tmp/krb5cc_0", O_RDONLY) = 13
... seek/read
[pid 9310] socket(PF_NETLINK, SOCK_RAW, 0) = 13
[pid 9310] bind(13, {sa_family=AF_NETLINK, pid=0, groups=},
12) = 0
[pid 9310] getsockname(13, {sa_family=AF_NETLINK, pid=9310,
groups=}, [4114028252329148428]) = 0
[pid 9310] sendto(13, "\24\0\0\0\26\0\1\3f#`G\0\0\0\0\0\0\0\0", 20, 0,
{sa_family=AF_NETLINK, pid=0, groups=}, 12) = 20
[pid 9310] recvmsg(13, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
groups=}, msg_iov(1)=[{...
...
I have the full trace, and can re-run to gather any pertinant data
It is extremely possible that I've screwed up the sendmail authinfo
data, but google has thus far proven extremely unhelpful
-- System Information:
Debian Release: lenny/sid
APT prefers testing-proposed-updates
APT policy: (500, 'testing-proposed-updates'), (500, 'proposed-updates'),
(500, 'oldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.23.9 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libsasl2-modules-gssapi-heimdal depends on:
ii libasn1-8-heimdal1.0.1-5 Heimdal Kerberos - ASN.1 library
ii libc62.7-4 GNU C Library: Shared libraries
ii libcomerr2 1.40.3-1common error description library
ii libgssapi2-heimdal 1.0.1-5 Heimdal Kerberos - GSSAPI support
ii libkrb5-22-heimdal 1.0.1-5 Heimdal Kerberos - libraries
ii libroken18-heimdal 1.0.1-5 Heimdal Kerberos - roken support l
ii libsasl2-modules 2.1.22.dfsg1-16 Cyrus SASL - pluggable authenticat
ii libssl0.9.8 0.9.8g-3SSL shared libraries
libsasl2-modules-gssapi-heimdal recommends no packages.
-- no debconf information
___
Pkg-cyrus-sasl2-debian-devel mailing list
[EMAIL PROTECTED]
http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-sasl2-debian-devel
-
Bug#433715: canon_user functionality for libsasl2-modules-ldap
Roberto, canon user functionality is described in the SASL Plugin Programmer's Guide: http://www.sendmail.org/~ca/email/cyrus2/plugprog.html We're using it to allow customers to authenticate as multiple identities but canonize to a single username when opening their mailbox (cyrus-imapd and pop3). We need this because we're in a long term transition from one username scheme to a newer one, and need to allow customers to login as either (or one of several) usernames. It could also support virtual domain hosting where the mailboxes might be, e.g., dwhite_example_com. The plugin could be used to cononize dwhite, dwhite-example and [EMAIL PROTECTED] to dwhite_example_com. We've been using perdition in the past to accomplish this, but this patch allows us to move away from that. As for why it's not included in upstream, I'm not sure. There was some discussion earlier this year on the cyrus-sasl list which included Howard Chu and also one of the guys who has CVS access. He said he was going to take a look at the patch, but the last time I checked, the patch hadn't been committed. Of course I'd much rather it come down from upstream. If you think that's more appropriate, I can try to raise the issue on the cyrus-sasl list again. If you're considering adding this patch, I'll can get a correct patch included in the bug (the one I submitted before missed a couple of file changes). Thanks, - Dan Roberto C.Sánchez wrote: Dan, et. al., I was reviewing some cyrus-sasl2 bugs today. It appears that canon_user functionality was requsted and a patch provided. What is canon_user funtionality? Why should it be in the Debian package (assuming it has not already been added upstream and thus will end up in a future release)? What is the potential impact of adding this patch? Regards, -Roberto ___ Pkg-cyrus-sasl2-debian-devel mailing list [EMAIL PROTECTED] http://lists.alioth.debian.org/mailman/listinfo/pkg-cyrus-sasl2-debian-devel
Bug#433715: libsasl2-modules-ldap: feature request for LDAP auxprop+canonuser implementation
Package: libsasl2-modules-ldap
Version: 2.1.22.dfsg1-13
Severity: wishlist
This is a combination of a couple of patches from the cyrus-sasl mailing
list:
http://osdir.com/ml/security.cyrus.sasl/2007-01/msg00053.html
http://archives.free.net.ph/message/20070522.142310.c4df1ddd.en.html
Both authored by Howard Chu.
This patch adds canon_user plugin functionality to the existing ldap
auxprop plugin.
*** /usr/src/ldapdb-canon.diff
--- ldapdb.c.orig 2007-04-11 17:29:07.0 -0500
+++ ldapdb.c2007-04-11 17:28:50.0 -0500
@@ -1,6 +1,6 @@
/* $OpenLDAP: pkg/ldap/contrib/ldapsasl/ldapdb.c,v 1.1.2.7 2003/11/29 22:10:03
hyc Exp $ */
-/* SASL LDAP auxprop implementation
- * Copyright (C) 2002,2003 Howard Chu, All rights reserved. <[EMAIL PROTECTED]>
+/* SASL LDAP auxprop+canonuser implementation
+ * Copyright (C) 2002-2007 Howard Chu, All rights reserved. <[EMAIL PROTECTED]>
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted only as authorized by the OpenLDAP
@@ -14,6 +14,7 @@
#include
#include
+#include
#include "sasl.h"
#include "saslutil.h"
@@ -26,13 +27,17 @@
static char ldapdb[] = "ldapdb";
typedef struct ldapctx {
+ int inited; /* Have we already read the config? */
const char *uri;/* URI of LDAP server */
struct berval id; /* SASL authcid to bind as */
struct berval pw; /* password for bind */
struct berval mech; /* SASL mech */
int use_tls;/* Issue StartTLS request? */
+ struct berval canon;/* Use attr in user entry for canonical name */
} ldapctx;
+static ldapctx ldapdb_ctx;
+
static int ldapdb_interact(LDAP *ld, unsigned flags __attribute__((unused)),
void *def, void *inter)
{
@@ -79,7 +84,7 @@
char *authzid;
if((i=ldap_initialize(&cp->ld, ctx->uri))) {
- return i;
+ return i;
}
authzid = sparams->utils->malloc(ulen + sizeof("u:"));
@@ -203,7 +208,7 @@
done:
if(attrs) sparams->utils->free(attrs);
-if(cp.ld) ldap_unbind(cp.ld);
+if(cp.ld) ldap_unbind_ext(cp.ld, NULL, NULL);
}
static int ldapdb_auxprop_store(void *glob_context,
@@ -254,58 +259,166 @@
if (i == LDAP_NO_MEMORY) i = SASL_NOMEM;
else i = SASL_FAIL;
}
-if (cp.ld) ldap_unbind(cp.ld);
+if(cp.ld) ldap_unbind_ext(cp.ld, NULL, NULL);
return i;
}
-static void ldapdb_auxprop_free(void *glob_ctx, const sasl_utils_t *utils)
+static int
+ldapdb_canon_server(void *glob_context,
+ sasl_server_params_t *sparams,
+ const char *user,
+ unsigned ulen,
+ unsigned flags,
+ char *out,
+ unsigned out_max,
+ unsigned *out_ulen)
{
- utils->free(glob_ctx);
+ldapctx *ctx = glob_context;
+connparm cp;
+struct berval **bvals;
+LDAPMessage *msg, *res;
+char *rdn, *attrs[2];
+unsigned len;
+int ret;
+
+if(!ctx || !sparams || !user) return SASL_BADPARAM;
+
+/* If no canon attribute was configured, we can't do anything */
+if(!ctx->canon.bv_val) return SASL_BADPARAM;
+
+/* Trim whitespace */
+while(isspace(*(unsigned char *)user)) {
+ user++;
+ ulen--;
+}
+while(isspace((unsigned char)user[ulen-1])) {
+ ulen--;
+}
+
+if (!ulen) {
+ sparams->utils->seterror(sparams->utils->conn, 0,
+ "All-whitespace username.");
+ return SASL_FAIL;
+}
+
+ret = ldapdb_connect(ctx, sparams, user, ulen, &cp);
+if ( ret ) goto done;
+
+/* See if the RDN uses the canon attr. If so, just use the RDN
+ * value, we don't need to do a search.
+ */
+rdn = cp.dn->bv_val+3;
+if (!strncasecmp(ctx->canon.bv_val, rdn, ctx->canon.bv_len) &&
+ rdn[ctx->canon.bv_len] == '=') {
+ char *comma;
+ rdn += ctx->canon.bv_len + 1;
+ comma = strchr(rdn, ',');
+ if ( comma )
+ len = comma - rdn;
+ else
+ len = cp.dn->bv_len - (rdn - cp.dn->bv_val);
+ if ( len > out_max )
+ len = out_max;
+ memcpy(out, rdn, len);
+ out[len] = '\0';
+ *out_ulen = len;
+ ret = SASL_OK;
+ ber_bvfree(cp.dn);
+ goto done;
+}
+
+/* Have to read the user's entry */
+attrs[0] = ctx->canon.bv_val;
+attrs[1] = NULL;
+ret = ldap_search_ext_s(cp.ld, cp.dn->bv_val+3, LDAP_SCOPE_BASE,
+ "(objectclass=*)", attrs, 0, cp.ctrl, NULL, NULL, 1, &res);
+ber_bvfree(cp.dn);
+
+if (ret != LDAP_SUCCESS) goto done;
+
+for(msg=ldap_first_message(cp.ld, res); msg; msg=ldap_next_message(cp.ld,
msg))
+{
+ if (ldap_msgtype(msg) != LDAP_RES_SEARCH_ENTRY) continue;
+ bvals = ldap_get_values_len(cp.ld, msg, attrs[0]);
+ if (!bvals) continue;
+ len = bvals[0]->bv_len;
+ if ( len > out_max )
+ len = out_max;
+
Bug#419420: Heimdal
Roberto C. Sánchez wrote: On Sun, Apr 15, 2007 at 01:21:42PM -0500, Dan White wrote: The following modifications give me a functioning heimdal module (inside of libsasl2-modules-gssapi-mit), which I'm using successfully so far on a test server: Modified debian/control Replaced build-depends on libkrb5-dev with heimdal-dev Removed dependency on libpq-dev Modified debian/rules Removed configure option --with-pgsql=/usr/include/postgresql Out of curiosity, why the removal of postgres support? I would think that we want the packages to be as identical as possible with the exception of the kerberos implementation used. libpq-dev depends on libkrb5-dev, which conflicts with heimdal-dev.
