Re: Cyrus IMAPd 2.3.10 Released
For confirmation, the problem I had a couple of weeks ago with Cyrus
2.3.10 on a Redhat 8 derived system is fixed by forcing
HAVE_GETGROUPLIST to be undefined (I did it by deleting getgrouplist
from the list of functions checked for in configure --- there's
presumably a cleaner way).
Begin forwarded message:
From: Ian G Batten [EMAIL PROTECTED]
Date: Thu 25 Oct 07 12:30:57 BDT
To: Ken Murchison [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], Cyrus Mailing List info-
[EMAIL PROTECTED]
Subject: Re: Cyrus IMAPd 2.3.10 Released
I've just compiled 2.3.10 on batten.eu.org (my private x86 servers)
and although it looks OK on the Solaris 10 system, it's in deep
trouble on the elderly Linux machine. Both are upgrades from 2.3.7,
the Solaris box is a replication target, the Linux box is a
replication master that handles deliver and reading. The intent is
to swap them over, and that intent might come sooner than I planned.
LSUB produces expected output, LIST doesn't (to put it mildly) and
examine/select can't select anything. strace on the running imapd
shows it's doing roughly sensible things: finding the correct
partition and metapartition from the mailbox database, opening the
metadata files correctly, but then it says NO. I've reconstructed
the mailbox, dumped and reloaded (ctl_mboxlist -d // ctl_mboxlist -u)
the mailboxes file and run reconstruct -G ``in case it makes any
odds''. No joy. And nothing useful in the logs, either...
read(0, . examine INBOX\r\n, 4096)= 17
fcntl64(6, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0})
= 0
fstat64(6, {st_mode=S_IFREG|0600, st_size=3520, ...}) = 0
stat64(/var/imap/mailboxes.db, {st_mode=S_IFREG|0600,
st_size=3520, ...}) = 0
fcntl64(6, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0})
= 0
fcntl64(6, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0})
= 0
fstat64(6, {st_mode=S_IFREG|0600, st_size=3520, ...}) = 0
stat64(/var/imap/mailboxes.db, {st_mode=S_IFREG|0600,
st_size=3520, ...}) = 0
fcntl64(6, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0})
= 0
open(/var/imap/metadata/user/igb/cyrus.header, O_RDWR) = 11
fstat64(11, {st_mode=S_IFREG|0600, st_size=250, ...}) = 0
mmap2(NULL, 250, PROT_READ, MAP_SHARED, 11, 0) = 0x40ee1000
open(/var/imap/metadata/user/igb/cyrus.index, O_RDWR) = 12
fstat64(12, {st_mode=S_IFREG|0600, st_size=204784, ...}) = 0
mmap2(NULL, 212992, PROT_READ, MAP_SHARED, 12, 0) = 0x40ef3000
open(/var/imap/metadata/user/igb/cyrus.cache, O_RDWR) = 13
fstat64(13, {st_mode=S_IFREG|0600, st_size=2753804, ...}) = 0
mmap2(NULL, 2768896, PROT_READ, MAP_SHARED, 13, 0) = 0x40f27000
fstat64(12, {st_mode=S_IFREG|0600, st_size=204784, ...}) = 0
close(11) = 0
munmap(0x40ee1000, 250) = 0
close(12) = 0
munmap(0x40ef3000, 212992) = 0
close(13) = 0
munmap(0x40f27000, 2768896) = 0
write(1, . NO Mailbox does not exist\r\n, 29) = 29
* OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=CRAM-MD5
AUTH=DIGEST-MD5 AUTH=LOGIN AUTH=PLAIN AUTH=OTP SASL-IR]
offsite.batten.eu.org Cyrus IMAP4 v2.3.10 server ready
. login igb X
. OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=CRAM-MD5
AUTH=DIGEST-MD5 AUTH=LOGIN AUTH=PLAIN AUTH=OTP SASL-IR ACL
RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS
NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT
SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE
CATENATE CONDSTORE IDLE URLAUTH] User logged in
. list *
* LIST (\HasNoChildren) . INBOX
. OK Completed (0.020 secs 2 calls)
. lsub *
* LSUB (\HasChildren) . INBOX
* LSUB () . INBOX.2003
* LSUB () . INBOX.2004
* LSUB () . INBOX.2005
* LSUB () . INBOX.2006
* LSUB () . INBOX.Drafts
* LSUB () . INBOX.Holidays
* LSUB () . INBOX.Junk
* LSUB () . INBOX.Sent
* LSUB () . INBOX.Trash
* LSUB () . INBOX.clamav
* LSUB () . INBOX.macos
* LSUB () . INBOX.pre-2003
* LSUB () . INBOX.twonky
* LSUB () . INBOX.xtension
. OK Completed (0.030 secs 16 calls)
. examine INBOX
. NO Mailbox does not exist
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
Simon Matter wrote: Hi, On Sun, 28 Oct 2007 19:42:02 +0100 Tomas Janousek [EMAIL PROTECTED] said: tjanouse Looks correct. (will not terminate if it reaches NGROUPS, don't know if that tjanouse can happen though) Oops, it never happen. It is intended to be safe-keeping for avoiding endless-loop. tjanouse But as I said earlier, it's probably better to use the old code on non-glibc tjanouse systems. I'm not sure which one is better. The implementation in 2.3.10 also segfaults on Linux systems unpatched glibc-2.3.2. From the getgrouplist manpage: BUGS The glibc 2.3.2 implementation of this function is broken: it overwrites memory when the actual number of groups is larger than *ngroups. Regards, Simon That's friggin' great! We can't exactly force people to have a particular version of glibc just to run Cyrus 2.3.10. Either we need to come up with something that will run on all systems, or I'll be inclined to remove the getgrouplist() code. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
Hi,
On Sun, 28 Oct 2007 19:42:02 +0100
Tomas Janousek [EMAIL PROTECTED] said:
tjanouse Looks correct. (will not terminate if it reaches NGROUPS, don't
know if that
tjanouse can happen though)
Oops, it never happen.
It is intended to be safe-keeping for avoiding endless-loop.
tjanouse But as I said earlier, it's probably better to use the old code
on non-glibc
tjanouse systems.
I'm not sure which one is better.
The implementation in 2.3.10 also segfaults on Linux systems unpatched
glibc-2.3.2. From the getgrouplist manpage:
BUGS
The glibc 2.3.2 implementation of this function is broken: it
overwrites memory when the actual number of groups is larger than
*ngroups.
Regards,
Simon
Index: lib/auth_unix.c
diff -u -p lib/auth_unix.c.orig lib/auth_unix.c
--- lib/auth_unix.c.orig 2007-09-28 05:02:45.0 +0900
+++ lib/auth_unix.c 2007-10-29 04:23:57.0 +0900
@@ -45,6 +45,9 @@
*/
#include config.h
+#ifdef HAVE_SYS_PARAM_H
+#include sys/param.h
+#endif
#include stdlib.h
#include pwd.h
#include grp.h
@@ -225,7 +228,12 @@ static struct auth_state *mynewstate(con
struct group *grp;
#ifdef HAVE_GETGROUPLIST
gid_t gid, *groupids = NULL;
-int ret, ngroups = 0;
+int ret = -1;
+#ifdef __GLIBC__
+int ngroups = 0;
+#else
+int ngroups = 5;
+#endif
#else
char **mem;
#endif
@@ -248,22 +256,35 @@ static struct auth_state *mynewstate(con
#ifdef HAVE_GETGROUPLIST
gid = pwd ? pwd-pw_gid : (gid_t) -1;
+#ifdef __GLIBC__
/* get number of groups user is member of into ngroups */
getgrouplist(identifier, gid, NULL, ngroups);
+#endif
/* get the actual group ids */
-do {
+for (;;) {
groupids = (gid_t *)xrealloc((gid_t *)groupids,
ngroups * sizeof(gid_t));
newstate-ngroups = ngroups; /* copy of ngroups for comparision */
ret = getgrouplist(identifier, gid, groupids, ngroups);
+ if (ret != -1)
+ break;
+#ifdef __GLIBC__
/*
* This is tricky. We do this as long as getgrouplist tells us to
* realloc _and_ the number of groups changes. It tells us to realloc
* also in the case of failure...
*/
-} while (ret != -1 ngroups != newstate-ngroups);
+ if (ngroups == newstate-ngroups)
+ break;
+#else
+ if (newstate-ngroups = NGROUPS)
+ break;
+ if ((ngroups = newstate-ngroups * 2) NGROUPS)
+ ngroups = NGROUPS;
+#endif
+}
if (ret == -1) {
newstate-ngroups = 0;
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org
http://www.imasy.org/~ume/
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
On Thu, Nov 08, 2007 at 06:39:45AM -0500, Ken Murchison wrote: That's friggin' great! We can't exactly force people to have a particular version of glibc just to run Cyrus 2.3.10. Either we need to come up with something that will run on all systems, or I'll be inclined to remove the getgrouplist() code. A quick search shows that at least Redhat, Mandrake and Gentoo issued security updates for this bug in Nov 2003; I'm pretty sure all other distros did the same. I do not think it is worth worrying about people who have not installed a security update for 4 years... IMHO if you want to avoid libc functions that had some bug on one system or other in the past then you will likely have to re-implement most of the C library... Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
On Thu, Nov 08, 2007 at 06:39:45AM -0500, Ken Murchison wrote: That's friggin' great! We can't exactly force people to have a particular version of glibc just to run Cyrus 2.3.10. Either we need to come up with something that will run on all systems, or I'll be inclined to remove the getgrouplist() code. A quick search shows that at least Redhat, Mandrake and Gentoo issued security updates for this bug in Nov 2003; I'm pretty sure all other distros did the same. I do not think it is worth worrying about people who have not installed a security update for 4 years... It may not be worth for you to worry about it but it is worth for me and maybe also for Ken. People using my RPMs expect things to work. And people do use it on affected systems and they fill my mailbox or the list with complaints if Cyrus segfaults for them. Simon Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
On Thu, Nov 08, 2007 at 07:36:24PM +0100, Simon Matter wrote: It may not be worth for you to worry about it but it is worth for me and maybe also for Ken. People using my RPMs expect things to work. And people do use it on affected systems and they fill my mailbox or the list with complaints if Cyrus segfaults for them. People using RPMs can just install the security updates just as easily as a new Cyrus RPM. The Red Hat advisory said a patch is available even for Red Hat 7.1; are you still actively maintaining packages for Red Hat 6.x? And what is better? Hiding the problem under the carpet, or saying See, you have a security bug that is known for 4 years. If you have a bug that old you probably have lots of other unfixed security bugs as well. Go fix your system!. If you do care about the users, you should educate them to always install security updates. Hi Gabor, Before it gets too OT, of course I understand your point but I still prefer a clean solution. Since work has to be done on the issue anyways for *BSD's, I'm quite sure the glibc issue can also be solved at the same time. Simon Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
On Thu, Nov 08, 2007 at 07:36:24PM +0100, Simon Matter wrote: It may not be worth for you to worry about it but it is worth for me and maybe also for Ken. People using my RPMs expect things to work. And people do use it on affected systems and they fill my mailbox or the list with complaints if Cyrus segfaults for them. People using RPMs can just install the security updates just as easily as a new Cyrus RPM. The Red Hat advisory said a patch is available even for Red Hat 7.1; are you still actively maintaining packages for Red Hat 6.x? RedHat 7.x is the lowest version where the package builds (which is also RHEL 2.1 level). But I don't know why this bug should have been fixed in RedHat 7.1, it has never existed there! What I know is that it has never been fixed in Fedora Core 1 and never been fixed in RedHat 9 (it has only been fixed in RedHat EL3). Both platforms are still widely used, believe it or not. Need examples, check out on which platforms the Slashdot webservers run! And what is better? Hiding the problem under the carpet, or saying See, you have a security bug that is known for 4 years. If you have a bug that old you probably have lots of other unfixed security bugs as well. Go fix your system!. If you do care about the users, you should educate them to always install security updates. That kind of thinking is part of the problem. I can't teach other people to take security serious but at the same time release an RPM package which segfaults on their systems. That way I make myself part of their problem. Simon Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
On Thu, Nov 08, 2007 at 07:36:24PM +0100, Simon Matter wrote: It may not be worth for you to worry about it but it is worth for me and maybe also for Ken. People using my RPMs expect things to work. And people do use it on affected systems and they fill my mailbox or the list with complaints if Cyrus segfaults for them. People using RPMs can just install the security updates just as easily as a new Cyrus RPM. The Red Hat advisory said a patch is available even for Red Hat 7.1; are you still actively maintaining packages for Red Hat 6.x? And what is better? Hiding the problem under the carpet, or saying See, you have a security bug that is known for 4 years. If you have a bug that old you probably have lots of other unfixed security bugs as well. Go fix your system!. If you do care about the users, you should educate them to always install security updates. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
Bron Gondwana wrote: On Sun, Nov 04, 2007 at 07:19:26PM -0800, Rich Wales wrote: What is the current status of 2.3.10? Right after it was announced a couple of weeks ago, I saw some people reporting problems. Are there any patches? Or is 2.3.10 still believed to be OK as is? I'm running 2.3.9 on a FreeBSD 6.2 master and an Ubuntu 7.10 replica server setup, and I want to upgrade to 2.3.10 in hopes of getting rid of some problems with the sync code intermittently crashing, but this is a production system, and I don't feel comfortable upgrading to 2.3.10 as long as there are unresolved serious bug reports. FastMail is running 2.3.10 on all our production systems now, and there are no regressions that I'm aware of. There are still some bugs that also existed in 2.3.9, but we aren't patching against any bugs rather than things that don't work how we would prefer. I have upgraded three (of seven) mailstores yesterday. Upgrade went without problems. Regeneration of the guid takes a long time. It's not finished yet, and its been running for 12 hours. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Rudy Gevaert [EMAIL PROTECTED] tel:+32 9 264 4734 Directie ICT, afd. Infrastructuur ICT Department, Infrastructure office Groep SystemenSystems group Universiteit Gent Ghent University Krijgslaan 281, gebouw S9, 9000 Gent, Belgie www.UGent.be -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
On Tue, Nov 06, 2007 at 08:57:29AM +0100, Rudy Gevaert wrote: Bron Gondwana wrote: On Sun, Nov 04, 2007 at 07:19:26PM -0800, Rich Wales wrote: What is the current status of 2.3.10? Right after it was announced a couple of weeks ago, I saw some people reporting problems. Are there any patches? Or is 2.3.10 still believed to be OK as is? I'm running 2.3.9 on a FreeBSD 6.2 master and an Ubuntu 7.10 replica server setup, and I want to upgrade to 2.3.10 in hopes of getting rid of some problems with the sync code intermittently crashing, but this is a production system, and I don't feel comfortable upgrading to 2.3.10 as long as there are unresolved serious bug reports. FastMail is running 2.3.10 on all our production systems now, and there are no regressions that I'm aware of. There are still some bugs that also existed in 2.3.9, but we aren't patching against any bugs rather than things that don't work how we would prefer. I have upgraded three (of seven) mailstores yesterday. Upgrade went without problems. Regeneration of the guid takes a long time. It's not finished yet, and its been running for 12 hours. That's why I pre-calculated all the sha1s I could and wrote my own index upgrader :) Yeah, it takes a while! Bron. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
On Sun, Nov 04, 2007 at 07:19:26PM -0800, Rich Wales wrote: What is the current status of 2.3.10? Right after it was announced a couple of weeks ago, I saw some people reporting problems. Are there any patches? Or is 2.3.10 still believed to be OK as is? I'm running 2.3.9 on a FreeBSD 6.2 master and an Ubuntu 7.10 replica server setup, and I want to upgrade to 2.3.10 in hopes of getting rid of some problems with the sync code intermittently crashing, but this is a production system, and I don't feel comfortable upgrading to 2.3.10 as long as there are unresolved serious bug reports. FastMail is running 2.3.10 on all our production systems now, and there are no regressions that I'm aware of. There are still some bugs that also existed in 2.3.9, but we aren't patching against any bugs rather than things that don't work how we would prefer. The two big new bugs that we found in the 2.3.10pre3 codebase when we rolled that out into production had their fixes accepted back upstream before the final 2.3.10 was cut. That said, we're seeing slightly more skiplist corruption than previously and have not yet determined the cause. We're backing up a text-dump of our mailboxes.db files once per hour just in case - but it's highly probable that the issues are due to something odd we're doing with long running cyr_dbtool processes. Bron. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
What is the current status of 2.3.10? Right after it was announced a couple of weeks ago, I saw some people reporting problems. Are there any patches? Or is 2.3.10 still believed to be OK as is? I'm running 2.3.9 on a FreeBSD 6.2 master and an Ubuntu 7.10 replica server setup, and I want to upgrade to 2.3.10 in hopes of getting rid of some problems with the sync code intermittently crashing, but this is a production system, and I don't feel comfortable upgrading to 2.3.10 as long as there are unresolved serious bug reports. -- Rich Wales === Palo Alto, CA, USA === [EMAIL PROTECTED] http://www.richw.org === http://en.wikipedia.org/wiki/User:Richwales The difference between theory and practice is that, in theory, theory and practice are identical -- whereas in practice, they aren't. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
Hi, On Sat, 27 Oct 2007 22:36:45 +0200 Tomas Janousek [EMAIL PROTECTED] said: tjanouse Hi, tjanouse On Sun, Oct 28, 2007 at 02:35:05AM +0900, Hajimu UMEMOTO wrote: tjanouse Yes. It should read ret == -1 ngroups != newstate-ngroups. I'm really tjanouse confused why I put the ret != -1 in there. As far as I read the FreeBSD's getgrouplist() implementation, when it returns -1, the number of the groups actually filled is set to ngroups. It is match with the following description in the manpage: RETURN VALUES The getgrouplist() function returns -1 if the size of the group list is too small to hold all the user's groups. Here, the group array will be filled with as many groups as will fit. tjanouse The manpage says that the actual number of groups found is returned in tjanouse ngroups. My understanding may be bad and/or they may have implemented tjanouse something else than they say in the manpage/than what I understand, though. tjanouse But I think this part of behaviour is really the same. If you really think tjanouse this is not what happens, I will check the sources. It seems to me from the source of getgrouplist() that it sets the actual number of groups found to ngroups only when it returns 0. When it returns -1, the number of groups actually filled is set to ngroups. I think that it is what the RETURN VALUES section in FreeBSD's manpage says. So, I think that ret == -1 ngroups != newstate-ngroups would be always FALSE at least on FreeBSD. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
Tomas Janousek wrote: Hi, On Sun, Oct 28, 2007 at 03:52:24PM +0900, Hajimu UMEMOTO wrote: It seems to me from the source of getgrouplist() that it sets the actual number of groups found to ngroups only when it returns 0. When it returns -1, the number of groups actually filled is set to ngroups. I think that it is what the RETURN VALUES section in FreeBSD's manpage says. Ok, I looked at the source and now I see it. And I think the source is really wrong (e.g. the write to groups without checking ngroups is non-zero -- this was fixed in glibc a looong time ago). So, I think that ret == -1 ngroups != newstate-ngroups would be always FALSE at least on FreeBSD. Yeah. To make it work on BSD, we should either preallocate big enough an array and don't care, or realloc to two-times the size whenever ngroups == newstate-ngroups (and to given size when ngroups newstate-ngroups, to make it faster on glibc). Thanks for catching this :) I don't have easy access to a BSD platform. Would somebody be willing to write and test such a patch? -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
Hi,
On Sun, 28 Oct 2007 09:57:45 -0400
Ken Murchison [EMAIL PROTECTED] said:
murch I don't have easy access to a BSD platform. Would somebody be willing
murch to write and test such a patch?
How about this patch?
Index: lib/auth_unix.c
diff -u -p lib/auth_unix.c.orig lib/auth_unix.c
--- lib/auth_unix.c.orig2007-09-28 05:02:45.0 +0900
+++ lib/auth_unix.c 2007-10-29 03:14:22.0 +0900
@@ -45,6 +45,9 @@
*/
#include config.h
+#ifdef HAVE_SYS_PARAM_H
+#include sys/param.h
+#endif
#include stdlib.h
#include pwd.h
#include grp.h
@@ -225,7 +228,12 @@ static struct auth_state *mynewstate(con
struct group *grp;
#ifdef HAVE_GETGROUPLIST
gid_t gid, *groupids = NULL;
-int ret, ngroups = 0;
+int ret = -1;
+#ifdef __GLIBC__
+int ngroups = 0;
+#else
+int ngroups = 5;
+#endif
#else
char **mem;
#endif
@@ -248,22 +256,33 @@ static struct auth_state *mynewstate(con
#ifdef HAVE_GETGROUPLIST
gid = pwd ? pwd-pw_gid : (gid_t) -1;
+#ifdef __GLIBC__
/* get number of groups user is member of into ngroups */
getgrouplist(identifier, gid, NULL, ngroups);
+#endif
/* get the actual group ids */
-do {
+while (ngroups = NGROUPS) {
groupids = (gid_t *)xrealloc((gid_t *)groupids,
ngroups * sizeof(gid_t));
newstate-ngroups = ngroups; /* copy of ngroups for comparision */
ret = getgrouplist(identifier, gid, groupids, ngroups);
+ if (ret != -1)
+ break;
+#ifdef __GLIBC__
/*
* This is tricky. We do this as long as getgrouplist tells us to
* realloc _and_ the number of groups changes. It tells us to realloc
* also in the case of failure...
*/
-} while (ret != -1 ngroups != newstate-ngroups);
+ if (ngroups == newstate-ngroups)
+ break;
+#else
+ if ((ngroups = newstate-ngroups * 2) NGROUPS)
+ ngroups = NGROUPS;
+#endif
+}
if (ret == -1) {
newstate-ngroups = 0;
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org
http://www.imasy.org/~ume/
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
Hi,
On Sun, 28 Oct 2007 19:42:02 +0100
Tomas Janousek [EMAIL PROTECTED] said:
tjanouse Looks correct. (will not terminate if it reaches NGROUPS, don't know
if that
tjanouse can happen though)
Oops, it never happen.
It is intended to be safe-keeping for avoiding endless-loop.
tjanouse But as I said earlier, it's probably better to use the old code on
non-glibc
tjanouse systems.
I'm not sure which one is better.
Index: lib/auth_unix.c
diff -u -p lib/auth_unix.c.orig lib/auth_unix.c
--- lib/auth_unix.c.orig2007-09-28 05:02:45.0 +0900
+++ lib/auth_unix.c 2007-10-29 04:23:57.0 +0900
@@ -45,6 +45,9 @@
*/
#include config.h
+#ifdef HAVE_SYS_PARAM_H
+#include sys/param.h
+#endif
#include stdlib.h
#include pwd.h
#include grp.h
@@ -225,7 +228,12 @@ static struct auth_state *mynewstate(con
struct group *grp;
#ifdef HAVE_GETGROUPLIST
gid_t gid, *groupids = NULL;
-int ret, ngroups = 0;
+int ret = -1;
+#ifdef __GLIBC__
+int ngroups = 0;
+#else
+int ngroups = 5;
+#endif
#else
char **mem;
#endif
@@ -248,22 +256,35 @@ static struct auth_state *mynewstate(con
#ifdef HAVE_GETGROUPLIST
gid = pwd ? pwd-pw_gid : (gid_t) -1;
+#ifdef __GLIBC__
/* get number of groups user is member of into ngroups */
getgrouplist(identifier, gid, NULL, ngroups);
+#endif
/* get the actual group ids */
-do {
+for (;;) {
groupids = (gid_t *)xrealloc((gid_t *)groupids,
ngroups * sizeof(gid_t));
newstate-ngroups = ngroups; /* copy of ngroups for comparision */
ret = getgrouplist(identifier, gid, groupids, ngroups);
+ if (ret != -1)
+ break;
+#ifdef __GLIBC__
/*
* This is tricky. We do this as long as getgrouplist tells us to
* realloc _and_ the number of groups changes. It tells us to realloc
* also in the case of failure...
*/
-} while (ret != -1 ngroups != newstate-ngroups);
+ if (ngroups == newstate-ngroups)
+ break;
+#else
+ if (newstate-ngroups = NGROUPS)
+ break;
+ if ((ngroups = newstate-ngroups * 2) NGROUPS)
+ ngroups = NGROUPS;
+#endif
+}
if (ret == -1) {
newstate-ngroups = 0;
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org
http://www.imasy.org/~ume/
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
Hi,
On Sat, 27 Oct 2007 14:02:59 +0200
Tomas Janousek [EMAIL PROTECTED] said:
tjanouse On Fri, Oct 26, 2007 at 03:30:30PM -0400, Ken Murchison wrote:
Perhaps, it should be:
do {
groupids = (gid_t *)xrealloc((gid_t *)groupids,
ngroups * sizeof(gid_t));
newstate-ngroups = ngroups; /* copy of ngroups for comparision */
ret = getgrouplist(identifier, gid, groupids, ngroups);
/*
* This is tricky. We do this as long as getgrouplist tells us to
* realloc _and_ the number of groups changes. It tells us to realloc
* also in the case of failure...
*/
} while (ret == -1 ngroups == newstate-ngroups);
~
I think you're right on the 'ret == -1' test. We want to stay in the loop
if getgrouplist() fails, AND it returns a different number of groups.
tjanouse Yes. It should read ret == -1 ngroups != newstate-ngroups. I'm
really
tjanouse confused why I put the ret != -1 in there.
As far as I read the FreeBSD's getgrouplist() implementation, when it
returns -1, the number of the groups actually filled is set to
ngroups. It is match with the following description in the manpage:
RETURN VALUES
The getgrouplist() function returns -1 if the size of the group list is
too small to hold all the user's groups. Here, the group array will be
filled with as many groups as will fit.
So, I think that ret == -1 ngroups != newstate-ngroups doesn't
work on at least FreeBSD.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org
http://www.imasy.org/~ume/
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
Simon Matter wrote: Simon Matter wrote: Simon Matter wrote: On the Linux box, all fresh compilations aside from the sasl 2.1.15 binaries: I once posted to the list that 2.3.9 needs at least cyrus-sasl-2.1.19. As a package maintainer I know that :) Did you ever figure out why? I'm not surprised that code in Cyrus I didn't investigate much once I found out that it's only sasl that needs an update. There was also a security issue with cyrus-sasl and I decided not to backport the fixes to 2.1.15 but instead upgrade sasl. Based on what John Capo has reported, I'm guessing that SASL 2.1.17 is required. I believe the following change in 2.1.17 is required for 2.3.9+ Thanks, I'll change the dependency in the next rpm release. Maybe this should also be noted in the release notes. I added this to install-upgrade.html -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
Quoting Ken Murchison ([EMAIL PROTECTED]):
John Capo wrote:
On Thu, October 25, 2007 21:10, John Capo wrote:
Quoting Ken Murchison ([EMAIL PROTECTED]):
Simon Matter wrote:
On the Linux box, all fresh compilations aside from the sasl 2.1.15
binaries:
I once posted to the list that 2.3.9 needs at least cyrus-sasl-2.1.19.
As a package
maintainer I know that :)
Did you ever figure out why? I'm not surprised that code in Cyrus
somehow depends on
a change in SASL, but I can't seem to find anything in the CVS logs or
diffs that
would be the cause.
This is what I had to do for cmd_login to work in 2.3.9.
/* authstate already created by mysasl_proxy_policy() */
/* Not when using login and allowplaintext. imapd_authstate is NULL TM
Login fix */
if (imapd_authstate == NULL)
imapd_authstate = auth_newstate(imapd_userid);
But 2.3.10 cores :-(
Its coring in getgrouplist() probably because the 3rd argyument is NULL.
/* get number of groups user is member of into ngroups */
getgrouplist(identifier, gid, NULL, ngroups);
BSD man page does not indicate that NULL args are OK.
int
getgrouplist(const char *name, int basegid, int *groups, int *ngroups);
The resulting group list is returned in the integer array pointed to by
groups. The caller specifies the size of the groups array in the integer
pointed to by ngroups; the actual number of groups found is returned in
ngroups.
See if this fixes the getgrouplist() problem:
It does fix the core dump. Our IMAP users are not in any Unix group
so I fully can't test that part.
--- auth_unix.c.~1.46.~ 2007-09-27 16:02:45.0 -0400
+++ auth_unix.c 2007-10-25 23:02:15.0 -0400
@@ -225,7 +225,7 @@
struct group *grp;
#ifdef HAVE_GETGROUPLIST
gid_t gid, *groupids = NULL;
-int ret, ngroups = 0;
+int ret, ngroups = 10;
#else
char **mem;
#endif
@@ -248,10 +248,7 @@
#ifdef HAVE_GETGROUPLIST
gid = pwd ? pwd-pw_gid : (gid_t) -1;
-/* get number of groups user is member of into ngroups */
-getgrouplist(identifier, gid, NULL, ngroups);
-
-/* get the actual group ids */
+/* get the group ids */
do {
groupids = (gid_t *)xrealloc((gid_t *)groupids,
ngroups * sizeof(gid_t));
--
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
John Capo wrote:
Quoting Ken Murchison ([EMAIL PROTECTED]):
John Capo wrote:
On Thu, October 25, 2007 21:10, John Capo wrote:
Quoting Ken Murchison ([EMAIL PROTECTED]):
Simon Matter wrote:
On the Linux box, all fresh compilations aside from the sasl 2.1.15
binaries:
I once posted to the list that 2.3.9 needs at least cyrus-sasl-2.1.19.
As a package
maintainer I know that :)
Did you ever figure out why? I'm not surprised that code in Cyrus
somehow depends on
a change in SASL, but I can't seem to find anything in the CVS logs or
diffs that
would be the cause.
This is what I had to do for cmd_login to work in 2.3.9.
/* authstate already created by mysasl_proxy_policy() */
/* Not when using login and allowplaintext. imapd_authstate is NULL TM
Login fix */
if (imapd_authstate == NULL)
imapd_authstate = auth_newstate(imapd_userid);
But 2.3.10 cores :-(
Its coring in getgrouplist() probably because the 3rd argyument is NULL.
/* get number of groups user is member of into ngroups */
getgrouplist(identifier, gid, NULL, ngroups);
BSD man page does not indicate that NULL args are OK.
int
getgrouplist(const char *name, int basegid, int *groups, int *ngroups);
The resulting group list is returned in the integer array pointed to by
groups. The caller specifies the size of the groups array in the integer
pointed to by ngroups; the actual number of groups found is returned in
ngroups.
See if this fixes the getgrouplist() problem:
It does fix the core dump. Our IMAP users are not in any Unix group
so I fully can't test that part.
--- auth_unix.c.~1.46.~ 2007-09-27 16:02:45.0 -0400
+++ auth_unix.c 2007-10-25 23:02:15.0 -0400
@@ -225,7 +225,7 @@
struct group *grp;
#ifdef HAVE_GETGROUPLIST
gid_t gid, *groupids = NULL;
-int ret, ngroups = 0;
+int ret, ngroups = 10;
#else
char **mem;
#endif
@@ -248,10 +248,7 @@
#ifdef HAVE_GETGROUPLIST
gid = pwd ? pwd-pw_gid : (gid_t) -1;
-/* get number of groups user is member of into ngroups */
-getgrouplist(identifier, gid, NULL, ngroups);
-
-/* get the actual group ids */
+/* get the group ids */
do {
groupids = (gid_t *)xrealloc((gid_t *)groupids,
ngroups * sizeof(gid_t));
Thanks for the update. Simon, since you're one of the original authors
of the getgrouplist() stuff, can you check the sanity of my changes?
--
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
Tomas Janousek wrote:
Hello,
On Fri, Oct 26, 2007 at 04:50:02PM +0200, Simon Matter wrote:
--- auth_unix.c.~1.46.~ 2007-09-27 16:02:45.0 -0400
+++ auth_unix.c 2007-10-25 23:02:15.0 -0400
@@ -225,7 +225,7 @@
struct group *grp;
#ifdef HAVE_GETGROUPLIST
gid_t gid, *groupids = NULL;
-int ret, ngroups = 0;
+int ret, ngroups = 10;
#else
char **mem;
#endif
@@ -248,10 +248,7 @@
#ifdef HAVE_GETGROUPLIST
gid = pwd ? pwd-pw_gid : (gid_t) -1;
-/* get number of groups user is member of into ngroups */
-getgrouplist(identifier, gid, NULL, ngroups);
-
-/* get the actual group ids */
+/* get the group ids */
do {
groupids = (gid_t *)xrealloc((gid_t *)groupids,
ngroups * sizeof(gid_t));
This should not change behaviour nor cause additional problems, I think.
The gnu manpage of getgrouplist does not mention the NULL case either, though
it works. If it segfaults, I'd consider that a libc failure, since when
ngroups == 0, the pointer shouldn't be used at all (it should point to the
first element of the array but array of 0 elements has no first element).
If it really is a wrong code of mine, then sorry for not testing on anything
other than Linux.
Its not a problem. Since we might have to realloc() the grouplist
anyways, it really doesn't make much sense to just get the count first.
--
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
Hajimu UMEMOTO wrote:
Hi,
On Thu, 25 Oct 2007 23:03:35 -0400
Ken Murchison [EMAIL PROTECTED] said:
murch John Capo wrote:
On Thu, October 25, 2007 21:10, John Capo wrote:
Quoting Ken Murchison ([EMAIL PROTECTED]):
Simon Matter wrote:
On the Linux box, all fresh compilations aside from the sasl 2.1.15
binaries:
I once posted to the list that 2.3.9 needs at least cyrus-sasl-2.1.19. As
a package
maintainer I know that :)
Did you ever figure out why? I'm not surprised that code in Cyrus somehow
depends on
a change in SASL, but I can't seem to find anything in the CVS logs or
diffs that
would be the cause.
This is what I had to do for cmd_login to work in 2.3.9.
/* authstate already created by mysasl_proxy_policy() */
/* Not when using login and allowplaintext. imapd_authstate is NULL TM
Login fix */
if (imapd_authstate == NULL)
imapd_authstate = auth_newstate(imapd_userid);
But 2.3.10 cores :-(
Its coring in getgrouplist() probably because the 3rd argyument is NULL.
/* get number of groups user is member of into ngroups */
getgrouplist(identifier, gid, NULL, ngroups);
BSD man page does not indicate that NULL args are OK.
int
getgrouplist(const char *name, int basegid, int *groups, int *ngroups);
The resulting group list is returned in the integer array pointed to by
groups. The caller specifies the size of the groups array in the integer
pointed to by ngroups; the actual number of groups found is returned in
ngroups.
murch See if this fixes the getgrouplist() problem:
murch --- auth_unix.c.~1.46.~2007-09-27 16:02:45.0 -0400
murch +++ auth_unix.c2007-10-25 23:02:15.0 -0400
murch @@ -225,7 +225,7 @@
murch struct group *grp;
murch #ifdef HAVE_GETGROUPLIST
murch gid_t gid, *groupids = NULL;
murch -int ret, ngroups = 0;
murch +int ret, ngroups = 10;
murch #else
murch char **mem;
murch #endif
murch @@ -248,10 +248,7 @@
murch #ifdef HAVE_GETGROUPLIST
murch gid = pwd ? pwd-pw_gid : (gid_t) -1;
murch -/* get number of groups user is member of into ngroups */
murch -getgrouplist(identifier, gid, NULL, ngroups);
murch -
murch -/* get the actual group ids */
murch +/* get the group ids */
murch do {
murchgroupids = (gid_t *)xrealloc((gid_t *)groupids,
murch ngroups * sizeof(gid_t));
The NGROUPS is defined in sys/param.h on BSDs as:
#define NGROUPS NGROUPS_MAX /* max number groups */
The NGROUPS_MAX is defined in sys/syslimits.h as:
#define NGROUPS_MAX16 /* max supplemental group id's */
and, sys/syslimits.h is included from sys/param.h. So, you should use
this instead of a magic number, IMHO.
From limits.h on my Fedora box:
#define NGROUPS_MAX65536
It seems like a waste of memory to use NGROUPS_MAX as the default size
on this platform.
--
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
Hi,
On Thu, 25 Oct 2007 23:03:35 -0400
Ken Murchison [EMAIL PROTECTED] said:
murch John Capo wrote:
On Thu, October 25, 2007 21:10, John Capo wrote:
Quoting Ken Murchison ([EMAIL PROTECTED]):
Simon Matter wrote:
On the Linux box, all fresh compilations aside from the sasl 2.1.15
binaries:
I once posted to the list that 2.3.9 needs at least cyrus-sasl-2.1.19. As
a package
maintainer I know that :)
Did you ever figure out why? I'm not surprised that code in Cyrus somehow
depends on
a change in SASL, but I can't seem to find anything in the CVS logs or
diffs that
would be the cause.
This is what I had to do for cmd_login to work in 2.3.9.
/* authstate already created by mysasl_proxy_policy() */
/* Not when using login and allowplaintext. imapd_authstate is NULL TM
Login fix */
if (imapd_authstate == NULL)
imapd_authstate = auth_newstate(imapd_userid);
But 2.3.10 cores :-(
Its coring in getgrouplist() probably because the 3rd argyument is NULL.
/* get number of groups user is member of into ngroups */
getgrouplist(identifier, gid, NULL, ngroups);
BSD man page does not indicate that NULL args are OK.
int
getgrouplist(const char *name, int basegid, int *groups, int *ngroups);
The resulting group list is returned in the integer array pointed to by
groups. The caller specifies the size of the groups array in the integer
pointed to by ngroups; the actual number of groups found is returned in
ngroups.
murch See if this fixes the getgrouplist() problem:
murch --- auth_unix.c.~1.46.~ 2007-09-27 16:02:45.0 -0400
murch +++ auth_unix.c 2007-10-25 23:02:15.0 -0400
murch @@ -225,7 +225,7 @@
murch struct group *grp;
murch #ifdef HAVE_GETGROUPLIST
murch gid_t gid, *groupids = NULL;
murch -int ret, ngroups = 0;
murch +int ret, ngroups = 10;
murch #else
murch char **mem;
murch #endif
murch @@ -248,10 +248,7 @@
murch #ifdef HAVE_GETGROUPLIST
murch gid = pwd ? pwd-pw_gid : (gid_t) -1;
murch -/* get number of groups user is member of into ngroups */
murch -getgrouplist(identifier, gid, NULL, ngroups);
murch -
murch -/* get the actual group ids */
murch +/* get the group ids */
murch do {
murch groupids = (gid_t *)xrealloc((gid_t *)groupids,
murch ngroups * sizeof(gid_t));
The NGROUPS is defined in sys/param.h on BSDs as:
#define NGROUPS NGROUPS_MAX /* max number groups */
The NGROUPS_MAX is defined in sys/syslimits.h as:
#define NGROUPS_MAX16 /* max supplemental group id's */
and, sys/syslimits.h is included from sys/param.h. So, you should use
this instead of a magic number, IMHO.
FYI: Though FreeBSD's getgrouplist() doesn't accept NULL for `groups',
it seems NetBSD's one accepts NULL.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org
http://www.imasy.org/~ume/
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
Hi,
On Fri, 26 Oct 2007 11:13:01 -0400
Ken Murchison [EMAIL PROTECTED] said:
murch Tomas Janousek wrote:
Hello,
On Fri, Oct 26, 2007 at 04:50:02PM +0200, Simon Matter wrote:
--- auth_unix.c.~1.46.~ 2007-09-27 16:02:45.0 -0400
+++ auth_unix.c 2007-10-25 23:02:15.0 -0400
@@ -225,7 +225,7 @@
struct group *grp;
#ifdef HAVE_GETGROUPLIST
gid_t gid, *groupids = NULL;
-int ret, ngroups = 0;
+int ret, ngroups = 10;
#else
char **mem;
#endif
@@ -248,10 +248,7 @@
#ifdef HAVE_GETGROUPLIST
gid = pwd ? pwd-pw_gid : (gid_t) -1;
-/* get number of groups user is member of into ngroups */
-getgrouplist(identifier, gid, NULL, ngroups);
-
-/* get the actual group ids */
+/* get the group ids */
do {
groupids = (gid_t *)xrealloc((gid_t *)groupids,
ngroups * sizeof(gid_t));
This should not change behaviour nor cause additional problems, I think.
The gnu manpage of getgrouplist does not mention the NULL case either, though
it works. If it segfaults, I'd consider that a libc failure, since when
ngroups == 0, the pointer shouldn't be used at all (it should point to the
first element of the array but array of 0 elements has no first element).
If it really is a wrong code of mine, then sorry for not testing on anything
other than Linux.
murch Its not a problem. Since we might have to realloc() the grouplist
murch anyways, it really doesn't make much sense to just get the count first.
The code is suspicious to me. Isn't the test of `ret != -1' is
opposite?
Further, it seems that the test of `ngroups == newstate-ngroups'
assumes that newstate-ngroups holds the actual number of groups
found, by calling getgrouplist() in the first place.
Perhaps, it should be:
do {
groupids = (gid_t *)xrealloc((gid_t *)groupids,
ngroups * sizeof(gid_t));
newstate-ngroups = ngroups; /* copy of ngroups for comparision */
ret = getgrouplist(identifier, gid, groupids, ngroups);
/*
* This is tricky. We do this as long as getgrouplist tells us to
* realloc _and_ the number of groups changes. It tells us to realloc
* also in the case of failure...
*/
} while (ret == -1 ngroups == newstate-ngroups);
~
I'm not sure that we can expect `ngroups == newstate-ngroups',
though.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org
http://www.imasy.org/~ume/
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
Hi, On Fri, 26 Oct 2007 12:40:31 -0400 Ken Murchison [EMAIL PROTECTED] said: murch From limits.h on my Fedora box: murch #define NGROUPS_MAX65536 murch It seems like a waste of memory to use NGROUPS_MAX as the default size murch on this platform. Umm, okay. Sorry for the noise. The group list is statically allocated in the FreeBSD kernel. It is somewhat limitation of FreeBSD. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
Hi,
Sat, 27 Oct 2007 02:31:32 +0900,
Hajimu UMEMOTO [EMAIL PROTECTED] said:
ume The code is suspicious to me. Isn't the test of `ret != -1' is
ume opposite?
ume Further, it seems that the test of `ngroups == newstate-ngroups'
ume assumes that newstate-ngroups holds the actual number of groups
ume found, by calling getgrouplist() in the first place.
ume Perhaps, it should be:
ume do {
umegroupids = (gid_t *)xrealloc((gid_t *)groupids,
ume ngroups * sizeof(gid_t));
umenewstate-ngroups = ngroups; /* copy of ngroups for comparision */
umeret = getgrouplist(identifier, gid, groupids, ngroups);
ume/*
ume * This is tricky. We do this as long as getgrouplist tells us to
ume * realloc _and_ the number of groups changes. It tells us to realloc
ume * also in the case of failure...
ume */
ume } while (ret == -1 ngroups == newstate-ngroups);
ume ~
ume I'm not sure that we can expect `ngroups == newstate-ngroups',
ume though.
Oops, I forgot to increase ngroups for next attempt.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org
http://www.imasy.org/~ume/
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
Hajimu UMEMOTO wrote:
Hi,
On Fri, 26 Oct 2007 11:13:01 -0400
Ken Murchison [EMAIL PROTECTED] said:
murch Tomas Janousek wrote:
Hello,
On Fri, Oct 26, 2007 at 04:50:02PM +0200, Simon Matter wrote:
--- auth_unix.c.~1.46.~ 2007-09-27 16:02:45.0 -0400
+++ auth_unix.c 2007-10-25 23:02:15.0 -0400
@@ -225,7 +225,7 @@
struct group *grp;
#ifdef HAVE_GETGROUPLIST
gid_t gid, *groupids = NULL;
-int ret, ngroups = 0;
+int ret, ngroups = 10;
#else
char **mem;
#endif
@@ -248,10 +248,7 @@
#ifdef HAVE_GETGROUPLIST
gid = pwd ? pwd-pw_gid : (gid_t) -1;
-/* get number of groups user is member of into ngroups */
-getgrouplist(identifier, gid, NULL, ngroups);
-
-/* get the actual group ids */
+/* get the group ids */
do {
groupids = (gid_t *)xrealloc((gid_t *)groupids,
ngroups * sizeof(gid_t));
This should not change behaviour nor cause additional problems, I think.
The gnu manpage of getgrouplist does not mention the NULL case either, though
it works. If it segfaults, I'd consider that a libc failure, since when
ngroups == 0, the pointer shouldn't be used at all (it should point to the
first element of the array but array of 0 elements has no first element).
If it really is a wrong code of mine, then sorry for not testing on anything
other than Linux.
murch Its not a problem. Since we might have to realloc() the grouplist
murch anyways, it really doesn't make much sense to just get the count first.
The code is suspicious to me. Isn't the test of `ret != -1' is
opposite?
Further, it seems that the test of `ngroups == newstate-ngroups'
assumes that newstate-ngroups holds the actual number of groups
found, by calling getgrouplist() in the first place.
Perhaps, it should be:
do {
groupids = (gid_t *)xrealloc((gid_t *)groupids,
ngroups * sizeof(gid_t));
newstate-ngroups = ngroups; /* copy of ngroups for comparision */
ret = getgrouplist(identifier, gid, groupids, ngroups);
/*
* This is tricky. We do this as long as getgrouplist tells us to
* realloc _and_ the number of groups changes. It tells us to realloc
* also in the case of failure...
*/
} while (ret == -1 ngroups == newstate-ngroups);
~
I think you're right on the 'ret == -1' test. We want to stay in the
loop if getgrouplist() fails, AND it returns a different number of
groups. Apparently, on Linux getgrouplist() can fail for some reason
other than ngroups being insufficient. So we want to break out of the
loop in this case.
Tomas, is my logic correct?
--
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
I've just compiled 2.3.10 on batten.eu.org (my private x86 servers)
and although it looks OK on the Solaris 10 system, it's in deep
trouble on the elderly Linux machine. Both are upgrades from 2.3.7,
the Solaris box is a replication target, the Linux box is a
replication master that handles deliver and reading. The intent is
to swap them over, and that intent might come sooner than I planned.
LSUB produces expected output, LIST doesn't (to put it mildly) and
examine/select can't select anything. strace on the running imapd
shows it's doing roughly sensible things: finding the correct
partition and metapartition from the mailbox database, opening the
metadata files correctly, but then it says NO. I've reconstructed
the mailbox, dumped and reloaded (ctl_mboxlist -d // ctl_mboxlist -u)
the mailboxes file and run reconstruct -G ``in case it makes any
odds''. No joy. And nothing useful in the logs, either...
read(0, . examine INBOX\r\n, 4096)= 17
fcntl64(6, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0})
= 0
fstat64(6, {st_mode=S_IFREG|0600, st_size=3520, ...}) = 0
stat64(/var/imap/mailboxes.db, {st_mode=S_IFREG|0600,
st_size=3520, ...}) = 0
fcntl64(6, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0})
= 0
fcntl64(6, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0})
= 0
fstat64(6, {st_mode=S_IFREG|0600, st_size=3520, ...}) = 0
stat64(/var/imap/mailboxes.db, {st_mode=S_IFREG|0600,
st_size=3520, ...}) = 0
fcntl64(6, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0})
= 0
open(/var/imap/metadata/user/igb/cyrus.header, O_RDWR) = 11
fstat64(11, {st_mode=S_IFREG|0600, st_size=250, ...}) = 0
mmap2(NULL, 250, PROT_READ, MAP_SHARED, 11, 0) = 0x40ee1000
open(/var/imap/metadata/user/igb/cyrus.index, O_RDWR) = 12
fstat64(12, {st_mode=S_IFREG|0600, st_size=204784, ...}) = 0
mmap2(NULL, 212992, PROT_READ, MAP_SHARED, 12, 0) = 0x40ef3000
open(/var/imap/metadata/user/igb/cyrus.cache, O_RDWR) = 13
fstat64(13, {st_mode=S_IFREG|0600, st_size=2753804, ...}) = 0
mmap2(NULL, 2768896, PROT_READ, MAP_SHARED, 13, 0) = 0x40f27000
fstat64(12, {st_mode=S_IFREG|0600, st_size=204784, ...}) = 0
close(11) = 0
munmap(0x40ee1000, 250) = 0
close(12) = 0
munmap(0x40ef3000, 212992) = 0
close(13) = 0
munmap(0x40f27000, 2768896) = 0
write(1, . NO Mailbox does not exist\r\n, 29) = 29
* OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=CRAM-MD5
AUTH=DIGEST-MD5 AUTH=LOGIN AUTH=PLAIN AUTH=OTP SASL-IR]
offsite.batten.eu.org Cyrus IMAP4 v2.3.10 server ready
. login igb X
. OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=CRAM-MD5
AUTH=DIGEST-MD5 AUTH=LOGIN AUTH=PLAIN AUTH=OTP SASL-IR ACL
RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS
NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT
SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE
CATENATE CONDSTORE IDLE URLAUTH] User logged in
. list *
* LIST (\HasNoChildren) . INBOX
. OK Completed (0.020 secs 2 calls)
. lsub *
* LSUB (\HasChildren) . INBOX
* LSUB () . INBOX.2003
* LSUB () . INBOX.2004
* LSUB () . INBOX.2005
* LSUB () . INBOX.2006
* LSUB () . INBOX.Drafts
* LSUB () . INBOX.Holidays
* LSUB () . INBOX.Junk
* LSUB () . INBOX.Sent
* LSUB () . INBOX.Trash
* LSUB () . INBOX.clamav
* LSUB () . INBOX.macos
* LSUB () . INBOX.pre-2003
* LSUB () . INBOX.twonky
* LSUB () . INBOX.xtension
. OK Completed (0.030 secs 16 calls)
. examine INBOX
. NO Mailbox does not exist
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
On 25 Oct 07, at 1230, Ian G Batten wrote: I've just compiled 2.3.10 on batten.eu.org (my private x86 servers) and although it looks OK on the Solaris 10 system, it's in deep trouble on the elderly Linux machine. Both are upgrades from 2.3.7, the Solaris box is a replication target, the Linux box is a replication master that handles deliver and reading. The intent is to swap them over, and that intent might come sooner than I planned. LSUB produces expected output, LIST doesn't (to put it mildly) and examine/select can't select anything. strace on the running imapd shows it's doing roughly sensible things: finding the correct partition and metapartition from the mailbox database, opening the metadata files correctly, but then it says NO. I've reconstructed the mailbox, dumped and reloaded (ctl_mboxlist -d // ctl_mboxlist - u) the mailboxes file and run reconstruct -G ``in case it makes any odds''. No joy. And nothing useful in the logs, either... Re-installing 2.3.7 has everything back working again (apart from replication to the now-2.3.10 replication target: I assume 2.3.7 master, 2.3.10 replica isn't supported). The Linux machine is very, very old (2.4.20, but the userland is a massively patched and upgraded Redhat 7.1). Looking at master's logs on 2.3.10 shows a lot of imapd processes getting signal 11: I'm going to hunt for the coredumps and see what's causing the issue. The version of db is very old, but I'm not using any db format databases any more. [EMAIL PROTECTED] igb]$ ldd /usr/cyrus/bin/imapd libsasl2.so.2 = /usr/local/lib/libsasl2.so.2 (0x4002) libssl.so.0.9.6 = /usr/lib/libssl.so.0.9.6 (0x40032000) libcrypto.so.0.9.6 = /usr/lib/libcrypto.so.0.9.6 (0x40061000) libresolv.so.2 = /lib/libresolv.so.2 (0x40122000) libdb-3.1.so = /lib/libdb-3.1.so (0x40134000) libnsl.so.1 = /lib/libnsl.so.1 (0x401ad000) libc.so.6 = /lib/i686/libc.so.6 (0x401c4000) libdl.so.2 = /lib/libdl.so.2 (0x4030) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) [EMAIL PROTECTED] igb]$ [EMAIL PROTECTED] igb]$ cat /etc/imapd.conf configdirectory: /var/imap partition-default: /var/imap/messages metapartition_files: header index cache expunge squat metapartition-default: /var/imap/metadata sievedir: /var/imap/sieve imap_admins: offsite lmtp_admins: deliver sasl_pwcheck_method: auxprop expunge_mode: delayed imaps_tls_cert_file: /var/imap/certs/imap-cert.pem imaps_tls_key_file: /var/imap/certs/imap-private.pem imap_tls_cert_file: /var/imap/certs/imap-cert.pem imap_tls_key_file: /var/imap/certs/imap-private.pem # there is no STARTTLS for POP3, so this can only happen over port 995 pop3s_tls_cert_file: /var/imap/certs/pop-cert.pem pop3s_tls_key_file: /var/imap/certs/pop-private.pem # there is ONLY STARTTLS for LMTP, so the service name is always lmtp lmtp_tls_cert_file: disabled lmtp_tls_key_file: disabled # same for everyone tls_ca_path: /var/imap/certs/ca sasl_maximum_layer: 0 tls_cipher_list: RC4 idled_shutdown_check: 0 annotation_db: skiplist duplicate_db: skiplist mboxlist_db: skiplist ptscache_db: skiplist seenstate_db: skiplist subscription_db: skiplist tlscache_db: skiplist sync_host: offsite2.batten.eu.org sync_authname: X sync_realm: X sync_password: XX sync_machineid: 1 sync_log: 1 allowplaintext: 1 [EMAIL PROTECTED] igb]$ * OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=OTP SASL-IR] offsite.batten.eu.org Cyrus IMAP4 v2.3.7 server ready . login igb XX . OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID LOGINDISABLED ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE IDLE URLAUTH] User logged in . select INBOX * FLAGS (\Answered \Flagged \Draft \Deleted \Seen Junk NonJunk $MDNSent $NotJunk $Junk JunkRecorded $Forwarded $Label1 $Label2 $Label3 $Label4 $Label5) * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen Junk NonJunk $MDNSent $NotJunk $Junk JunkRecorded $Forwarded $Label1 $Label2 $Label3 $Label4 $Label5 \*)] * 2326 EXISTS * 0 RECENT * OK [UNSEEN 2325] * OK [UIDVALIDITY 1033487767] * OK [UIDNEXT 17663] * OK [NOMODSEQ] Sorry, modsequences have not been enabled on this mailbox . OK [READ-WRITE] Completed Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
What does imapd.conf look like?
Does the output of 'ctl_mboxlist -d' look reasonable?
Does 'mbexamine user.igb' look reasonable?
Ian G Batten wrote:
I've just compiled 2.3.10 on batten.eu.org (my private x86 servers) and
although it looks OK on the Solaris 10 system, it's in deep trouble on
the elderly Linux machine. Both are upgrades from 2.3.7, the Solaris
box is a replication target, the Linux box is a replication master that
handles deliver and reading. The intent is to swap them over, and that
intent might come sooner than I planned.
LSUB produces expected output, LIST doesn't (to put it mildly) and
examine/select can't select anything. strace on the running imapd shows
it's doing roughly sensible things: finding the correct partition and
metapartition from the mailbox database, opening the metadata files
correctly, but then it says NO. I've reconstructed the mailbox, dumped
and reloaded (ctl_mboxlist -d // ctl_mboxlist -u) the mailboxes file and
run reconstruct -G ``in case it makes any odds''. No joy. And nothing
useful in the logs, either...
read(0, . examine INBOX\r\n, 4096)= 17
fcntl64(6, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = 0
fstat64(6, {st_mode=S_IFREG|0600, st_size=3520, ...}) = 0
stat64(/var/imap/mailboxes.db, {st_mode=S_IFREG|0600, st_size=3520,
...}) = 0
fcntl64(6, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}) = 0
fcntl64(6, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = 0
fstat64(6, {st_mode=S_IFREG|0600, st_size=3520, ...}) = 0
stat64(/var/imap/mailboxes.db, {st_mode=S_IFREG|0600, st_size=3520,
...}) = 0
fcntl64(6, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}) = 0
open(/var/imap/metadata/user/igb/cyrus.header, O_RDWR) = 11
fstat64(11, {st_mode=S_IFREG|0600, st_size=250, ...}) = 0
mmap2(NULL, 250, PROT_READ, MAP_SHARED, 11, 0) = 0x40ee1000
open(/var/imap/metadata/user/igb/cyrus.index, O_RDWR) = 12
fstat64(12, {st_mode=S_IFREG|0600, st_size=204784, ...}) = 0
mmap2(NULL, 212992, PROT_READ, MAP_SHARED, 12, 0) = 0x40ef3000
open(/var/imap/metadata/user/igb/cyrus.cache, O_RDWR) = 13
fstat64(13, {st_mode=S_IFREG|0600, st_size=2753804, ...}) = 0
mmap2(NULL, 2768896, PROT_READ, MAP_SHARED, 13, 0) = 0x40f27000
fstat64(12, {st_mode=S_IFREG|0600, st_size=204784, ...}) = 0
close(11) = 0
munmap(0x40ee1000, 250) = 0
close(12) = 0
munmap(0x40ef3000, 212992) = 0
close(13) = 0
munmap(0x40f27000, 2768896) = 0
write(1, . NO Mailbox does not exist\r\n, 29) = 29
* OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=CRAM-MD5
AUTH=DIGEST-MD5 AUTH=LOGIN AUTH=PLAIN AUTH=OTP SASL-IR]
offsite.batten.eu.org Cyrus IMAP4 v2.3.10 server ready
. login igb X
. OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=CRAM-MD5
AUTH=DIGEST-MD5 AUTH=LOGIN AUTH=PLAIN AUTH=OTP SASL-IR ACL RIGHTS=kxte
QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT
CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT
THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE IDLE URLAUTH] User
logged in
. list *
* LIST (\HasNoChildren) . INBOX
. OK Completed (0.020 secs 2 calls)
. lsub *
* LSUB (\HasChildren) . INBOX
* LSUB () . INBOX.2003
* LSUB () . INBOX.2004
* LSUB () . INBOX.2005
* LSUB () . INBOX.2006
* LSUB () . INBOX.Drafts
* LSUB () . INBOX.Holidays
* LSUB () . INBOX.Junk
* LSUB () . INBOX.Sent
* LSUB () . INBOX.Trash
* LSUB () . INBOX.clamav
* LSUB () . INBOX.macos
* LSUB () . INBOX.pre-2003
* LSUB () . INBOX.twonky
* LSUB () . INBOX.xtension
. OK Completed (0.030 secs 16 calls)
. examine INBOX
. NO Mailbox does not exist
--
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
Ian G Batten wrote: On 25 Oct 07, at 1248, Ken Murchison wrote: What does imapd.conf look like? Does the output of 'ctl_mboxlist -d' look reasonable? Does 'mbexamine user.igb' look reasonable? OK, there's a steady stream of imapd processes being forked and then dying on SIGSEGV. I've caught one in the act. That looks SASL-y: I'll check the versions and upgrade. If the 2.3.10 imapd's are all dying, then how were you able to connect to one which fails to SELECT? Are you compiling Cyrus yourself? Are you working in separate directories for each version, or just using the same CVS sandbox? If you're working from one directory, make sure you do a complete rebuild (make clean; make all). I've seen weird behavior when only part of the source tree is rebuilt. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
Ian G Batten wrote: On 25 Oct 07, at 1230, Ian G Batten wrote: I've just compiled 2.3.10 on batten.eu.org (my private x86 servers) and although it looks OK on the Solaris 10 system, it's in deep trouble on the elderly Linux machine. Both are upgrades from 2.3.7, the Solaris box is a replication target, the Linux box is a replication master that handles deliver and reading. The intent is to swap them over, and that intent might come sooner than I planned. LSUB produces expected output, LIST doesn't (to put it mildly) and examine/select can't select anything. strace on the running imapd shows it's doing roughly sensible things: finding the correct partition and metapartition from the mailbox database, opening the metadata files correctly, but then it says NO. I've reconstructed the mailbox, dumped and reloaded (ctl_mboxlist -d // ctl_mboxlist -u) the mailboxes file and run reconstruct -G ``in case it makes any odds''. No joy. And nothing useful in the logs, either... Re-installing 2.3.7 has everything back working again (apart from replication to the now-2.3.10 replication target: I assume 2.3.7 master, 2.3.10 replica isn't supported). The Linux machine is very, very old (2.4.20, but the userland is a massively patched and upgraded Redhat 7.1). Looking at master's logs on 2.3.10 shows a lot of imapd processes getting signal 11: I'm going to hunt for the coredumps and see what's causing the issue. The version of db is very old, but I'm not using any db format databases any more. [EMAIL PROTECTED] igb]$ ldd /usr/cyrus/bin/imapd libsasl2.so.2 = /usr/local/lib/libsasl2.so.2 (0x4002) libssl.so.0.9.6 = /usr/lib/libssl.so.0.9.6 (0x40032000) libcrypto.so.0.9.6 = /usr/lib/libcrypto.so.0.9.6 (0x40061000) libresolv.so.2 = /lib/libresolv.so.2 (0x40122000) libdb-3.1.so = /lib/libdb-3.1.so (0x40134000) libnsl.so.1 = /lib/libnsl.so.1 (0x401ad000) libc.so.6 = /lib/i686/libc.so.6 (0x401c4000) libdl.so.2 = /lib/libdl.so.2 (0x4030) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) [EMAIL PROTECTED] igb]$ [EMAIL PROTECTED] igb]$ cat /etc/imapd.conf configdirectory: /var/imap partition-default: /var/imap/messages metapartition_files: header index cache expunge squat metapartition-default: /var/imap/metadata sievedir: /var/imap/sieve imap_admins: offsite lmtp_admins: deliver sasl_pwcheck_method: auxprop expunge_mode: delayed imaps_tls_cert_file: /var/imap/certs/imap-cert.pem imaps_tls_key_file: /var/imap/certs/imap-private.pem imap_tls_cert_file: /var/imap/certs/imap-cert.pem imap_tls_key_file: /var/imap/certs/imap-private.pem # there is no STARTTLS for POP3, so this can only happen over port 995 pop3s_tls_cert_file: /var/imap/certs/pop-cert.pem pop3s_tls_key_file: /var/imap/certs/pop-private.pem # there is ONLY STARTTLS for LMTP, so the service name is always lmtp lmtp_tls_cert_file: disabled lmtp_tls_key_file: disabled # same for everyone tls_ca_path: /var/imap/certs/ca sasl_maximum_layer: 0 tls_cipher_list: RC4 idled_shutdown_check: 0 Are you applying third-party patches? 'idled_shutdown_check' isn't a valid option in the stock distro. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
Ian G Batten wrote: On 25 Oct 07, at 1248, Ken Murchison wrote: What does imapd.conf look like? See second mail. Does the output of 'ctl_mboxlist -d' look reasonable? Yes. ctl_mboxlist -d /tmp/foo ctl_mboxlist -u /tmp/foo ctl_mboxlist -d | diff -c - /tmp/foo Check /tmp/foo for @domain part in folder acl. If it present, remove domain part, import /tmp/foo and restart server. WBR. Dmitriy Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
idled_shutdown_check: 0 Are you applying third-party patches? 'idled_shutdown_check' isn't a valid option in the stock distro. No: the config dates back to the dawn of time, but the installation today is a straight download and compile. ian Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
On 25 Oct 07, at 1248, Ken Murchison wrote:
What does imapd.conf look like?
See second mail.
Does the output of 'ctl_mboxlist -d' look reasonable?
Yes.
ctl_mboxlist -d /tmp/foo
ctl_mboxlist -u /tmp/foo
ctl_mboxlist -d | diff -c - /tmp/foo
comes up clean, too.
Does 'mbexamine user.igb' look reasonable?
I don't know what reasonable looks like, I get this. At first blush
the Index Header info looks the same as running the same command on
the Solaris replica, which seems much healthier.
I can flip between 2.3.7 and 2.3.10 (2.3.7 works, 2.3.10 doesn't) so
I'm fairly certain there's nothing overly toxic about the mailboxes.
ian
[EMAIL PROTECTED] cyrus-imapd-2.3.10]# /usr/cyrus/bin/mbexamine user.igb
Examining user.igb...
Mailbox Header Info:
Path to mailbox: /var/imap/messages/user/igb
Mailbox ACL: igb lrswipcda
Unique ID: 3ab028613d99c597
User Flags: Junk NonJunk $MDNSent $NotJunk $Junk JunkRecorded
$Forwarded $Label1 $Label2 $Label3 $Label4 $Label5
Index Header Info:
Generation Number: -1040070997
Format: NORMAL
Minor Version: 10
Header Size: 96 bytes Record Size: 88 bytes
Number of Messages: 2326 Mailbox Size: 57125014 bytes
Last Append Date: (1193308980) Thu Oct 25 11:43:00 2007
UIDValidity: 1033487767 Last UID: 17662
Deleted: 0 Answered: 464 Flagged: 0
Mailbox Options: POP3_NEW_UIDL
Last POP3 Login: (0) Thu Jan 1 01:00:00 1970
Highest Mod Sequence: 1
Message Info:
01 UID:8642 INT_DATE:1151761881 SENTDATE:1151751600 SIZE:
32648
HDRSIZE:2855 LASTUPD :1193311454 SYSFLAGS: LINES:
535
CACHEVER:2 GUID:
MODSEQ:1
USERFLAGS: 0008
Envel{314}(Sat, 01 Jul 2006 08:50:25 -0500 (CDT) Returned mail:
User unknown ((NIL NIL postoffice batten.eu.org)) ((NIL NIL
postoffice batten.eu.org)) ((NIL NIL postoffice
batten.eu.org)) ((Mail Delivery Subsystem NIL MAILER-DAEMON
batten.eu.org)) NIL NIL NIL [EMAIL PROTECTED])
and then a lot more of the same.
Ian G Batten wrote:
I've just compiled 2.3.10 on batten.eu.org (my private x86
servers) and although it looks OK on the Solaris 10 system, it's
in deep trouble on the elderly Linux machine. Both are upgrades
from 2.3.7, the Solaris box is a replication target, the Linux box
is a replication master that handles deliver and reading. The
intent is to swap them over, and that intent might come sooner
than I planned.
LSUB produces expected output, LIST doesn't (to put it mildly) and
examine/select can't select anything. strace on the running imapd
shows it's doing roughly sensible things: finding the correct
partition and metapartition from the mailbox database, opening the
metadata files correctly, but then it says NO. I've reconstructed
the mailbox, dumped and reloaded (ctl_mboxlist -d // ctl_mboxlist -
u) the mailboxes file and run reconstruct -G ``in case it makes
any odds''. No joy. And nothing useful in the logs, either...
read(0, . examine INBOX\r\n, 4096)= 17
fcntl64(6, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0,
len=0}) = 0
fstat64(6, {st_mode=S_IFREG|0600, st_size=3520, ...}) = 0
stat64(/var/imap/mailboxes.db, {st_mode=S_IFREG|0600,
st_size=3520, ...}) = 0
fcntl64(6, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0,
len=0}) = 0
fcntl64(6, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0,
len=0}) = 0
fstat64(6, {st_mode=S_IFREG|0600, st_size=3520, ...}) = 0
stat64(/var/imap/mailboxes.db, {st_mode=S_IFREG|0600,
st_size=3520, ...}) = 0
fcntl64(6, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0,
len=0}) = 0
open(/var/imap/metadata/user/igb/cyrus.header, O_RDWR) = 11
fstat64(11, {st_mode=S_IFREG|0600, st_size=250, ...}) = 0
mmap2(NULL, 250, PROT_READ, MAP_SHARED, 11, 0) = 0x40ee1000
open(/var/imap/metadata/user/igb/cyrus.index, O_RDWR) = 12
fstat64(12, {st_mode=S_IFREG|0600, st_size=204784, ...}) = 0
mmap2(NULL, 212992, PROT_READ, MAP_SHARED, 12, 0) = 0x40ef3000
open(/var/imap/metadata/user/igb/cyrus.cache, O_RDWR) = 13
fstat64(13, {st_mode=S_IFREG|0600, st_size=2753804, ...}) = 0
mmap2(NULL, 2768896, PROT_READ, MAP_SHARED, 13, 0) = 0x40f27000
fstat64(12, {st_mode=S_IFREG|0600, st_size=204784, ...}) = 0
close(11) = 0
munmap(0x40ee1000, 250) = 0
close(12) = 0
munmap(0x40ef3000, 212992) = 0
close(13) = 0
munmap(0x40f27000, 2768896) = 0
write(1, . NO Mailbox does not exist\r\n, 29) = 29
* OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=CRAM-
MD5 AUTH=DIGEST-MD5 AUTH=LOGIN AUTH=PLAIN AUTH=OTP SASL-IR]
offsite.batten.eu.org Cyrus IMAP4 v2.3.10 server ready
. login igb X
. OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=CRAM-
MD5 AUTH=DIGEST-MD5 AUTH=LOGIN AUTH=PLAIN AUTH=OTP SASL-IR ACL
Re: Cyrus IMAPd 2.3.10 Released
On 10/25/07, Ian G Batten [EMAIL PROTECTED] wrote:
I've just compiled 2.3.10 on batten.eu.org (my private x86 servers)
and although it looks OK on the Solaris 10 system, it's in deep
trouble on the elderly Linux machine. Both are upgrades from 2.3.7,
the Solaris box is a replication target, the Linux box is a
replication master that handles deliver and reading. The intent is
to swap them over, and that intent might come sooner than I planned.
LSUB produces expected output, LIST doesn't (to put it mildly) and
examine/select can't select anything. strace on the running imapd
shows it's doing roughly sensible things: finding the correct
partition and metapartition from the mailbox database, opening the
metadata files correctly, but then it says NO. I've reconstructed
the mailbox, dumped and reloaded (ctl_mboxlist -d // ctl_mboxlist -u)
the mailboxes file and run reconstruct -G ``in case it makes any
odds''. No joy. And nothing useful in the logs, either...
read(0, . examine INBOX\r\n, 4096)= 17
fcntl64(6, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0})
= 0
fstat64(6, {st_mode=S_IFREG|0600, st_size=3520, ...}) = 0
stat64(/var/imap/mailboxes.db, {st_mode=S_IFREG|0600,
st_size=3520, ...}) = 0
fcntl64(6, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0})
= 0
fcntl64(6, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0})
= 0
fstat64(6, {st_mode=S_IFREG|0600, st_size=3520, ...}) = 0
stat64(/var/imap/mailboxes.db, {st_mode=S_IFREG|0600,
st_size=3520, ...}) = 0
fcntl64(6, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0})
= 0
open(/var/imap/metadata/user/igb/cyrus.header, O_RDWR) = 11
fstat64(11, {st_mode=S_IFREG|0600, st_size=250, ...}) = 0
mmap2(NULL, 250, PROT_READ, MAP_SHARED, 11, 0) = 0x40ee1000
open(/var/imap/metadata/user/igb/cyrus.index, O_RDWR) = 12
fstat64(12, {st_mode=S_IFREG|0600, st_size=204784, ...}) = 0
mmap2(NULL, 212992, PROT_READ, MAP_SHARED, 12, 0) = 0x40ef3000
open(/var/imap/metadata/user/igb/cyrus.cache, O_RDWR) = 13
fstat64(13, {st_mode=S_IFREG|0600, st_size=2753804, ...}) = 0
mmap2(NULL, 2768896, PROT_READ, MAP_SHARED, 13, 0) = 0x40f27000
fstat64(12, {st_mode=S_IFREG|0600, st_size=204784, ...}) = 0
close(11) = 0
munmap(0x40ee1000, 250) = 0
close(12) = 0
munmap(0x40ef3000, 212992) = 0
close(13) = 0
munmap(0x40f27000, 2768896) = 0
write(1, . NO Mailbox does not exist\r\n, 29) = 29
* OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=CRAM-MD5
AUTH=DIGEST-MD5 AUTH=LOGIN AUTH=PLAIN AUTH=OTP SASL-IR]
offsite.batten.eu.org Cyrus IMAP4 v2.3.10 server ready
. login igb X
. OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=CRAM-MD5
AUTH=DIGEST-MD5 AUTH=LOGIN AUTH=PLAIN AUTH=OTP SASL-IR ACL
RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS
NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT
SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE
CATENATE CONDSTORE IDLE URLAUTH] User logged in
. list *
* LIST (\HasNoChildren) . INBOX
. OK Completed (0.020 secs 2 calls)
. lsub *
* LSUB (\HasChildren) . INBOX
* LSUB () . INBOX.2003
* LSUB () . INBOX.2004
* LSUB () . INBOX.2005
* LSUB () . INBOX.2006
* LSUB () . INBOX.Drafts
* LSUB () . INBOX.Holidays
* LSUB () . INBOX.Junk
* LSUB () . INBOX.Sent
* LSUB () . INBOX.Trash
* LSUB () . INBOX.clamav
* LSUB () . INBOX.macos
* LSUB () . INBOX.pre-2003
* LSUB () . INBOX.twonky
* LSUB () . INBOX.xtension
. OK Completed (0.030 secs 16 calls)
. examine INBOX
. NO Mailbox does not exist
I thinks this is the same reply, when you dont have enought right on a mailbox.
can you try to execute myright INBOX using imtest for example ?
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
--
Alain Spineux
aspineux gmail com
May the sources be with you
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
On the Linux box, all fresh compilations aside from the sasl 2.1.15 binaries: imapd 2.3.7 + sasl 2.1.15: works imapd 2.3.7 + sasl 2.1.22: works imapd 2.3.9 + sasl 2.1.15: not tried imapd 2.3.9 + sasl 2.1.22: works imapd 2.3.10 + sasl 2.1.15: fails (cannot examine mailboxes, then coredumps prior to calling accept for second connection) imapd 2.3.10 + sasl 2.1.22: fails (SIGSEGV immediately after authentication) I've compiled 2.3.10 both -O2 and with optimisation turned off, to no effect. This is God's way of telling me to move onto a newer OS platform, I think. I'll stick at 2.3.9 + 2.1.22, since it appears to work and it's obviously a better proposition that the 2.3.7+2.1.15 I was running previously. It seems clear the problem has come in with 2.3.10, and as the platform is horrid I'll stop investigating further. In the mean time, is there any way I can run replication from a master running 2.3.9 into a replica running 2.3.10? Or should I back the replica out to 2.3.9 as well? ian Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
On 25 Oct 07, at 1248, Ken Murchison wrote:
What does imapd.conf look like?
Does the output of 'ctl_mboxlist -d' look reasonable?
Does 'mbexamine user.igb' look reasonable?
OK, there's a steady stream of imapd processes being forked and then
dying on SIGSEGV. I've caught one in the act. That looks SASL-y:
I'll check the versions and upgrade.
ian
[pid 29202] ... select resumed ) = 1 (in [0], left {1799,
69})
[pid 29202] time(NULL) = 1193314959
[pid 29202] time(NULL) = 1193314959
[pid 29202] select(1, [0], NULL, NULL, {1800, 0}) = 1 (in [0], left
{1800, 0})
[pid 29202] time(NULL) = 1193314959
[pid 29202] time(NULL) = 1193314959
[pid 29202] read(0, 1 AUTHENTICATE CRAM-MD5\r\n, 4096) = 25
[pid 29202] time(NULL) = 1193314959
[pid 29202] open(/dev/random, O_RDONLY) = 11
[pid 29202] read(11, \257gK\352F\213, 6) = 6
[pid 29202] close(11) = 0
[pid 29202] gettimeofday({1193314959, 565907}, NULL) = 0
[pid 29202] times({tms_utime=2, tms_stime=2, tms_cutime=0,
tms_cstime=0}) = 1055799906
[pid 29202] write(1, + PDU0NjI4NTkyMC4yMTMyNjk0QG9mZn..., 60) = 60
[pid 29202] time(NULL) = 1193314959
[pid 29202] select(1, [0], NULL, NULL, {1800, 0}) = 1 (in [0], left
{1799, 78})
[pid 29202] time(NULL) = 1193314959
[pid 29202] time(NULL) = 1193314959
[pid 29202] read(0, aWdiIDVlNjMzNTk2MWY5OWFlZDExYmFh..., 4096) = 50
[pid 29202] open(/etc/sasldb2, O_RDONLY) = 11
[pid 29202] fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
[pid 29202] fstat64(11, {st_mode=S_IFREG|0660, st_size=12288, ...}) = 0
[pid 29202] lseek(11, 0, SEEK_SET) = 0
[pid 29202] read(11, \0\0\0\0\0\0\0\0\0\0\0\0a\25\6\0\7\0\0\0\0\20\0
\0\0\10..., 256) = 256
[pid 29202] close(11) = 0
[pid 29202] stat64(/var/tmp, {st_mode=S_IFDIR|S_ISVTX|0777,
st_size=104, ...}) = 0
[pid 29202] brk(0x817a000) = 0x817a000
[pid 29202] mmap2(NULL, 274432, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_ANONYMOUS, -1, 0) = 0x40ef3000
[pid 29202] open(/etc/sasldb2, O_RDONLY) = 11
[pid 29202] fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
[pid 29202] fstat64(11, {st_mode=S_IFREG|0660, st_size=12288, ...}) = 0
[pid 29202] lseek(11, 0, SEEK_SET) = 0
[pid 29202] read(11, \0\0\0\0\0\0\0\0\0\0\0\0a\25\6\0\7\0\0\0\0\20\0
\0\0\10..., 4096) = 4096
[pid 29202] brk(0x817c000) = 0x817c000
[pid 29202] lseek(11, 4096, SEEK_SET) = 4096
[pid 29202] read(11, \0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0.\0\202
\t\0\2\331..., 4096) = 4096
[pid 29202] close(11) = 0
[pid 29202] munmap(0x40ef3000, 274432) = 0
[pid 29202] open(/etc/sasldb2, O_RDONLY) = 11
[pid 29202] fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
[pid 29202] fstat64(11, {st_mode=S_IFREG|0660, st_size=12288, ...}) = 0
[pid 29202] lseek(11, 0, SEEK_SET) = 0
[pid 29202] read(11, \0\0\0\0\0\0\0\0\0\0\0\0a\25\6\0\7\0\0\0\0\20\0
\0\0\10..., 256) = 256
[pid 29202] close(11) = 0
[pid 29202] stat64(/var/tmp, {st_mode=S_IFDIR|S_ISVTX|0777,
st_size=104, ...}) = 0
[pid 29202] mmap2(NULL, 274432, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_ANONYMOUS, -1, 0) = 0x40ef3000
[pid 29202] open(/etc/sasldb2, O_RDONLY) = 11
[pid 29202] fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
[pid 29202] fstat64(11, {st_mode=S_IFREG|0660, st_size=12288, ...}) = 0
[pid 29202] lseek(11, 0, SEEK_SET) = 0
[pid 29202] read(11, \0\0\0\0\0\0\0\0\0\0\0\0a\25\6\0\7\0\0\0\0\20\0
\0\0\10..., 4096) = 4096
[pid 29202] lseek(11, 4096, SEEK_SET) = 4096
[pid 29202] read(11, \0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0.\0\202
\t\0\2\331..., 4096) = 4096
[pid 29202] close(11) = 0
[pid 29202] munmap(0x40ef3000, 274432) = 0
[pid 29202] socket(PF_UNIX, SOCK_STREAM, 0) = 11
[pid 29202] connect(11, {sin_family=AF_UNIX,
path=
/var/run/.nscd_socket}, 110) = -1 ENOENT (No
such file or directory)
[pid 29202] close(11) = 0
[pid 29202] open(/etc/passwd, O_RDONLY) = 11
[pid 29202] fcntl64(11, F_GETFD)= 0
[pid 29202] fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
[pid 29202] fstat64(11, {st_mode=S_IFREG|0644, st_size=1710, ...}) = 0
[pid 29202] mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_ANONYMOUS, -1, 0) = 0x40ee1000
[pid 29202] read(11, root:x:0:0:root:/root:/bin/bash\n..., 4096) =
1710
[pid 29202] close(11) = 0
[pid 29202] munmap(0x40ee1000, 4096)= 0
[pid 29202] open(/etc/group, O_RDONLY) = 11
[pid 29202] fcntl64(11, F_GETFD)= 0
[pid 29202] fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
[pid 29202] fstat64(11, {st_mode=S_IFREG|0644, st_size=725, ...}) = 0
[pid 29202] mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_ANONYMOUS, -1, 0) = 0x40ee1000
[pid 29202] _llseek(11, 0, [0], SEEK_CUR) = 0
[pid 29202] read(11, root:x:0:root\nbin:x:1:root,bin,d..., 4096) = 725
[pid 29202] read(11, , 4096)
Re: Cyrus IMAPd 2.3.10 Released
Ian G Batten wrote: On the Linux box, all fresh compilations aside from the sasl 2.1.15 binaries: imapd 2.3.7 + sasl 2.1.15: works imapd 2.3.7 + sasl 2.1.22: works imapd 2.3.9 + sasl 2.1.15: not tried imapd 2.3.9 + sasl 2.1.22: works imapd 2.3.10 + sasl 2.1.15: fails (cannot examine mailboxes, then coredumps prior to calling accept for second connection) imapd 2.3.10 + sasl 2.1.22: fails (SIGSEGV immediately after authentication) I've compiled 2.3.10 both -O2 and with optimisation turned off, to no effect. This is God's way of telling me to move onto a newer OS platform, I think. I'll stick at 2.3.9 + 2.1.22, since it appears to work and it's obviously a better proposition that the 2.3.7+2.1.15 I was running previously. It seems clear the problem has come in with 2.3.10, and as the platform is horrid I'll stop investigating further. In the mean time, is there any way I can run replication from a master running 2.3.9 into a replica running 2.3.10? Or should I back the replica out to 2.3.9 as well? Back the replica down to 2.3.9. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
On 25 Oct 07, at 1501, Ken Murchison wrote: Ian G Batten wrote: On the Linux box, all fresh compilations aside from the sasl 2.1.15 binaries: imapd 2.3.7 + sasl 2.1.15: works imapd 2.3.7 + sasl 2.1.22: works imapd 2.3.9 + sasl 2.1.15: not tried imapd 2.3.9 + sasl 2.1.22: works imapd 2.3.10 + sasl 2.1.15: fails (cannot examine mailboxes, then coredumps prior to calling accept for second connection) imapd 2.3.10 + sasl 2.1.22: fails (SIGSEGV immediately after authentication) I've compiled 2.3.10 both -O2 and with optimisation turned off, to no effect. This is God's way of telling me to move onto a newer OS platform, I think. I'll stick at 2.3.9 + 2.1.22, since it appears to work and it's obviously a better proposition that the 2.3.7+2.1.15 I was running previously. It seems clear the problem has come in with 2.3.10, and as the platform is horrid I'll stop investigating further. In the mean time, is there any way I can run replication from a master running 2.3.9 into a replica running 2.3.10? Or should I back the replica out to 2.3.9 as well? Back the replica down to 2.3.9. Done, and replication is re-established. I'll try to replicate the problem without users breathing down my neck (ftel.co.uk has 1000 users, batten.eu.org has six, but they're my parents, my wife and my children), but I suspect it's some horrid combination of elderly libraries misbehaving. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
On the Linux box, all fresh compilations aside from the sasl 2.1.15 binaries: I once posted to the list that 2.3.9 needs at least cyrus-sasl-2.1.19. As a package maintainer I know that :) Regards, Simon imapd 2.3.7 + sasl 2.1.15: works imapd 2.3.7 + sasl 2.1.22: works imapd 2.3.9 + sasl 2.1.15: not tried imapd 2.3.9 + sasl 2.1.22: works imapd 2.3.10 + sasl 2.1.15: fails (cannot examine mailboxes, then coredumps prior to calling accept for second connection) imapd 2.3.10 + sasl 2.1.22: fails (SIGSEGV immediately after authentication) I've compiled 2.3.10 both -O2 and with optimisation turned off, to no effect. This is God's way of telling me to move onto a newer OS platform, I think. I'll stick at 2.3.9 + 2.1.22, since it appears to work and it's obviously a better proposition that the 2.3.7+2.1.15 I was running previously. It seems clear the problem has come in with 2.3.10, and as the platform is horrid I'll stop investigating further. In the mean time, is there any way I can run replication from a master running 2.3.9 into a replica running 2.3.10? Or should I back the replica out to 2.3.9 as well? ian Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
Simon Matter wrote: On the Linux box, all fresh compilations aside from the sasl 2.1.15 binaries: I once posted to the list that 2.3.9 needs at least cyrus-sasl-2.1.19. As a package maintainer I know that :) Did you ever figure out why? I'm not surprised that code in Cyrus somehow depends on a change in SASL, but I can't seem to find anything in the CVS logs or diffs that would be the cause. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
Simon Matter wrote: On the Linux box, all fresh compilations aside from the sasl 2.1.15 binaries: I once posted to the list that 2.3.9 needs at least cyrus-sasl-2.1.19. As a package maintainer I know that :) Did you ever figure out why? I'm not surprised that code in Cyrus I didn't investigate much once I found out that it's only sasl that needs an update. There was also a security issue with cyrus-sasl and I decided not to backport the fixes to 2.1.15 but instead upgrade sasl. Simon Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
On Thu, October 25, 2007 21:10, John Capo wrote: Quoting Ken Murchison ([EMAIL PROTECTED]): Simon Matter wrote: On the Linux box, all fresh compilations aside from the sasl 2.1.15 binaries: I once posted to the list that 2.3.9 needs at least cyrus-sasl-2.1.19. As a package maintainer I know that :) Did you ever figure out why? I'm not surprised that code in Cyrus somehow depends on a change in SASL, but I can't seem to find anything in the CVS logs or diffs that would be the cause. This is what I had to do for cmd_login to work in 2.3.9. /* authstate already created by mysasl_proxy_policy() */ /* Not when using login and allowplaintext. imapd_authstate is NULL TM Login fix */ if (imapd_authstate == NULL) imapd_authstate = auth_newstate(imapd_userid); But 2.3.10 cores :-( Its coring in getgrouplist() probably because the 3rd argyument is NULL. /* get number of groups user is member of into ngroups */ getgrouplist(identifier, gid, NULL, ngroups); BSD man page does not indicate that NULL args are OK. int getgrouplist(const char *name, int basegid, int *groups, int *ngroups); The resulting group list is returned in the integer array pointed to by groups. The caller specifies the size of the groups array in the integer pointed to by ngroups; the actual number of groups found is returned in ngroups. A non NULL imapd_authstate and turing off unix_group_enable works with older SASL libraries and 2.3.10. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
Hello Simon, When your latest source rpm can be available on your download site? I wonder when the statuscache could be offically patched... BTW, the renaming folder patch requires admin ppl to cleanup (renamed) folders by script. Is it possible possible to purge them immediately while users change them? thx patrick - Original Message - From: Simon Matter [EMAIL PROTECTED] To: Ian G Batten [EMAIL PROTECTED] Cc: Ken Murchison [EMAIL PROTECTED]; Cyrus Mailing List info-cyrus@lists.andrew.cmu.edu Sent: Thursday, October 25, 2007 11:01 PM Subject: Re: Cyrus IMAPd 2.3.10 Released On the Linux box, all fresh compilations aside from the sasl 2.1.15 binaries: I once posted to the list that 2.3.9 needs at least cyrus-sasl-2.1.19. As a package maintainer I know that :) Regards, Simon imapd 2.3.7 + sasl 2.1.15: works imapd 2.3.7 + sasl 2.1.22: works imapd 2.3.9 + sasl 2.1.15: not tried imapd 2.3.9 + sasl 2.1.22: works imapd 2.3.10 + sasl 2.1.15: fails (cannot examine mailboxes, then coredumps prior to calling accept for second connection) imapd 2.3.10 + sasl 2.1.22: fails (SIGSEGV immediately after authentication) I've compiled 2.3.10 both -O2 and with optimisation turned off, to no effect. This is God's way of telling me to move onto a newer OS platform, I think. I'll stick at 2.3.9 + 2.1.22, since it appears to work and it's obviously a better proposition that the 2.3.7+2.1.15 I was running previously. It seems clear the problem has come in with 2.3.10, and as the platform is horrid I'll stop investigating further. In the mean time, is there any way I can run replication from a master running 2.3.9 into a replica running 2.3.10? Or should I back the replica out to 2.3.9 as well? ian Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
Hello Simon, When your latest source rpm can be available on your download site? Hi Patrick, This could take some time because I also have to wait for some patches to get updated, or do it myself where I can. I did an 2.3.10-RC package but found that a number changes require some bigger updates of patches. Simon I wonder when the statuscache could be offically patched... BTW, the renaming folder patch requires admin ppl to cleanup (renamed) folders by script. Is it possible possible to purge them immediately while users change them? thx patrick - Original Message - From: Simon Matter [EMAIL PROTECTED] To: Ian G Batten [EMAIL PROTECTED] Cc: Ken Murchison [EMAIL PROTECTED]; Cyrus Mailing List info-cyrus@lists.andrew.cmu.edu Sent: Thursday, October 25, 2007 11:01 PM Subject: Re: Cyrus IMAPd 2.3.10 Released On the Linux box, all fresh compilations aside from the sasl 2.1.15 binaries: I once posted to the list that 2.3.9 needs at least cyrus-sasl-2.1.19. As a package maintainer I know that :) Regards, Simon imapd 2.3.7 + sasl 2.1.15: works imapd 2.3.7 + sasl 2.1.22: works imapd 2.3.9 + sasl 2.1.15: not tried imapd 2.3.9 + sasl 2.1.22: works imapd 2.3.10 + sasl 2.1.15: fails (cannot examine mailboxes, then coredumps prior to calling accept for second connection) imapd 2.3.10 + sasl 2.1.22: fails (SIGSEGV immediately after authentication) I've compiled 2.3.10 both -O2 and with optimisation turned off, to no effect. This is God's way of telling me to move onto a newer OS platform, I think. I'll stick at 2.3.9 + 2.1.22, since it appears to work and it's obviously a better proposition that the 2.3.7+2.1.15 I was running previously. It seems clear the problem has come in with 2.3.10, and as the platform is horrid I'll stop investigating further. In the mean time, is there any way I can run replication from a master running 2.3.9 into a replica running 2.3.10? Or should I back the replica out to 2.3.9 as well? ian Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
Simon Matter wrote: Simon Matter wrote: On the Linux box, all fresh compilations aside from the sasl 2.1.15 binaries: I once posted to the list that 2.3.9 needs at least cyrus-sasl-2.1.19. As a package maintainer I know that :) Did you ever figure out why? I'm not surprised that code in Cyrus I didn't investigate much once I found out that it's only sasl that needs an update. There was also a security issue with cyrus-sasl and I decided not to backport the fixes to 2.1.15 but instead upgrade sasl. Based on what John Capo has reported, I'm guessing that SASL 2.1.17 is required. I believe the following change in 2.1.17 is required for 2.3.9+ Thanks, I'll change the dependency in the next rpm release. Maybe this should also be noted in the release notes. Simon Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
