Re: [Dovecot] Segfault in deliver server
Timo Sirainen writes: > On Tue, 2009-02-03 at 12:04 +0100, Sascha Wilde wrote: >> #0 array_idx_modifiable_i (array=0x38, idx=0) at array.c:10 >> #1 0x0805e9a2 in sql_pool_unlink (ctx=0x80fb670) at sql-pool.c:64 > > Sorry, took a while to get around to looking at this. I think this > should fix it: http://hg.dovecot.org/dovecot-1.2/rev/533e4829212a > > I guess no one has before been removing connections from the sql pool. Thanks Timo, as I didn't stumble across this problem lately I merely forgot about it my self... cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpXdfhLZLxCL.pgp Description: PGP signature
Re: [Dovecot] v1.2: can't access other users shared INBOX
Sascha Wilde writes: > Before going back to the details in this discussion I want to point out > that the whole thing turned out to be really relevant with existing > clients: The Horde based Kolab WebClient expects the behavior as shown > by Cyrus IMAP and fails to show "user/a...@example.com/INBOX" as dovecot > currently lists A's INBOX. This analysis was plain wrong. The true problem was that a001 LIST "" "user/a...@example.com/%" did not list "user/a...@example.com/INBOX"... See Bernhard's mail on this subject, including a fix. cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpHbY6LaLxqt.pgp Description: PGP signature
Re: [Dovecot] v1.2: can't access other users shared INBOX
Bernhard Herzog writes: [...] > As it turns out, there is one problem the patch doesn't address. It fixes > the > problem of listing the INBOX when the search pattern is simply "*", but > dovecot still doesn't list the inbox of user fred if the pattern > is "users/fred/%" (or however the shared namespace is configured). The > reason is that "INBOX" simply doesn't match the pattern. The namespace > prefix has to be taken into account when doing the match. The updated patch > below fixes this. Thanks, that fixes the reported problem as well as the problems I experienced with the Horde-WebClient (and falsely blamed on the use of "INBOX" in the mailbox name). Timo, is it possible to merge Bernhard's fixes in dovecot-1.2 tip? cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpDqDTVv6xfR.pgp Description: PGP signature
Re: [Dovecot] v1.2: can't access other users shared INBOX
Hi *, Before going back to the details in this discussion I want to point out that the whole thing turned out to be really relevant with existing clients: The Horde based Kolab WebClient expects the behavior as shown by Cyrus IMAP and fails to show "user/a...@example.com/INBOX" as dovecot currently lists A's INBOX. While this might be considered a bug in Horde it shows that existing clients actually highly depend on the behavior as seen in Cyrus IMAP. Timo Sirainen writes: > On Tue, 2009-03-17 at 18:20 +0100, Sascha Wilde wrote: >> >> 1) "user/a...@example.com" really should be accessible to user B. >> >>Why is it listed with "\Noselect"? >> > >> > I'm not sure it should be accessible. This is most likely not A's INBOX. >> > That's the other folder you're trying to access: >> >> >> 2) "user/a...@example.com/INBOX" does not exist, so the error message is >> >>correct, but why does it appear in the listing in the first place? >> >> This might very well be true, but in this case dovecot behaves different >> From cyrus -- which might still be RfC conforming (I haven't checked, >> but from my memories the RfC is very unspecific on these topics anyway). > > Are you talking about 1) or 2)? I'm talking about 1 vs 2 if you will. ;-) I expected "user/a...@example.com" to be A's INBOX, while BH pointed out, that with the current implementation it is more likely that "user/a...@example.com/INBOX" actually refers to A's INBOX. > If 1), RFC doesn't talk about it. And > I'm not really sure if it's a good idea to default the a...@example.com to > be the same as INBOX. If Cyrus does that, Yes, cyrus does that. > does it then not show the a...@example.com/INBOX? No, it doesn't as, the INBOX of A is referred to as "user/a...@example.com", so "a...@example.com/INBOX" would actually be an folder named "INBOX". Which would be displayed as "INBOX/INBOX" from A's point of view: User A: when shared to User B maps to: INBOX user/a...@example.com INBOX/foo user/a...@example.com/foo INBOX/foo/bar user/a...@example.com/foo/bar cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpAXc5A8CCaf.pgp Description: PGP signature
Re: [Dovecot] v1.2: can't access other users shared INBOX
Bernhard Herzog writes: > On 04.03.2009, Sascha Wilde wrote: [...] >> User B: >> >> l list "" "*" >> * LIST (\Noselect \HasChildren) "/" "user" >> * LIST (\Noselect \HasChildren) "/" "user/a...@example.com" >> * LIST (\HasChildren) "/" "INBOX" >> * LIST (\HasNoChildren) "/" "INBOX/Gesendet" >> * LIST (\HasChildren) "/" "user/a...@example.com/foobar" >> * LIST (\HasNoChildren) "/" "user/a...@example.com/INBOX" >> l OK List completed. >> s1 select "user/a...@example.com" >> s1 NO [CANNOT] Invalid mailbox name >> s2 select "user/a...@example.com/INBOX" >> s2 NO [NONEXISTENT] Mailbox doesn't exist: INBOX >> >> Actually there are two bugs to observe here: >> >> 1) "user/a...@example.com" really should be accessible to user B. >>Why is it listed with "\Noselect"? > > I'm not sure it should be accessible. This is most likely not A's INBOX. > That's the other folder you're trying to access: >> 2) "user/a...@example.com/INBOX" does not exist, so the error message is >>correct, but why does it appear in the listing in the first place? This might very well be true, but in this case dovecot behaves different From cyrus -- which might still be RfC conforming (I haven't checked, but from my memories the RfC is very unspecific on these topics anyway). I only hope that this difference is not to confusing to (Kolab) clients... [...] > The solution I'm testing is to simply remove the test for the > NAMESPACE_FLAG_INBOX flag (see patch below). Thanks! I'll give it a try. cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpyRKnRseQqk.pgp Description: PGP signature
Re: [Dovecot] ACLs are applied recursively to sub mailboxes
Timo Sirainen writes: > On Wed, 2009-03-04 at 17:01 +0100, Sascha Wilde wrote: >> Hi *, >> >> The problem is most noticeable when a user shares his INBOX[0][1] with >> others: >> >> User A sets his INBOX acls to "eilprwtsd" >> >> Now User B can see _all_ sub mailboxes and sub sub [...] mailboxes and >> their contents of User A: > > That shouldn't happen. There's no code for doing recursive ACLs. Sounds > more like a bug somewhere. I'll check it later. Hi, have you already found the time to have a look at it? Otherwise it might be a good idea if we (== any of the Kolab people at Intevation) had a look at some of the ACL problems I reported? cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpSW5XORcrjS.pgp Description: PGP signature
Re: [Dovecot] ACL changes not respected by already loged in clients
Steffen Kaiser writes: > On Thu, 5 Mar 2009, Sascha Wilde wrote: > >> I think ACL changes should take immediate effect, or at least should be >> re-checked in reasonable intervals (which imo shouldn't exceed a few >> seconds). > > Although I see the problem in your scenario, it is rather uncommon to > recalculate ACLs for already running processes, esp. not in intervals of > seconds. When you say "uncommon", which references are you referring to? There are not too many other imap server implementations implementing this features (imap acl and shared user mailboxes). I only tested the (widely used) cyrus imapd, which promotes ACL changes immediately. > Did you tried it in Windows or Unix? Afaik dovecot doesn't even run on Windows systems. > Maybe, some "ACL push" plugin would help, that pushes ACL changes to > processes that are logged in currently. This might be a good way to implement things efficiently but before doing so I would prefer to evaluate if simply rechecking the relevant ACLs on each IMAP command has such a big performance impact that this kind of optimization is really needed. cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpbTdcUXylGl.pgp Description: PGP signature
[Dovecot] ACL changes not respected by already loged in clients
Hi *, and yet another ACL problem. ;-) User A allows User B to access his mailbox foobar: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN] Dovecot ready. l login userA secret l OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT THREAD=REFERENCES MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH ACL RIGHTS=texk ANNOTATEMORE] Logged in s setacl "INBOX/foobar" "b...@example.com" eilprwtsd s OK Setacl complete. g getacl INBOX/foobar * ACL "INBOX/foobar" "b...@example.com" eilprwtsd "a...@example.com" lrwstipekxacd User B logs in to dovecot and sees the newly accessible mailbox: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN] Dovecot ready. l login zwei 2 l OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT THREAD=REFERENCES MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH ACL RIGHTS=texk ANNOTATEMORE] Logged in l list "" "*" * LIST (\Noselect \HasChildren) "/" "user" * LIST (\Noselect \HasChildren) "/" "user/a...@example.com" * LIST (\HasChildren) "/" "INBOX" * LIST (\HasNoChildren) "/" "INBOX/Gesendet" * LIST (\HasChildren) "/" "user/a...@example.com/foobar" l OK List completed. se select "user/a...@example.com/foobar" * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted. * 1 EXISTS * 1 RECENT * OK [UIDVALIDITY 1236104897] UIDs valid * OK [UIDNEXT 2] Predicted next UID * OK [HIGHESTMODSEQ 1] Now User A changes his mind: s setacl "INBOX/foobar" "b...@example.com" "" s OK Setacl complete. g getacl INBOX/foobar * ACL "INBOX/foobar" "a...@example.com" lrwstipekxacd g OK Getacl completed. but as long as User B stays loged in, he is not affected, in fact he still can read A's mails: se select "user/a...@example.com/foobar" * OK [CLOSED] * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted. * 1 EXISTS * 0 RECENT * OK [UIDVALIDITY 1236104897] UIDs valid * OK [UIDNEXT 2] Predicted next UID * OK [HIGHESTMODSEQ 1] se OK [READ-WRITE] Select completed. f101 fetch 1 FAST * 1 FETCH (FLAGS (\Seen) INTERNALDATE "04-Mar-2009 13:11:06 +0100" RFC822.SIZE 3652) f101 OK Fetch completed. I think ACL changes should take immediate effect, or at least should be re-checked in reasonable intervals (which imo shouldn't exceed a few seconds). cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpZ0JyX5aW0O.pgp Description: PGP signature
Re: [Dovecot] ACLs are applied recursively to sub mailboxes
Sascha Wilde writes: > Timo Sirainen writes: >> On Wed, 2009-03-04 at 17:01 +0100, Sascha Wilde wrote: >>> * LIST (\HasChildren) "/" "user/1...@aztec.intevation.de/foobar" >> >> [...] Is the mailbox also selectable? Oh, missed to answer that question: yes, it is selectable and the contents is actually accessible from an ordinary imap client. cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpqGvzJ8df8L.pgp Description: PGP signature
Re: [Dovecot] ACLs are applied recursively to sub mailboxes
Timo Sirainen writes: > On Wed, 2009-03-04 at 17:01 +0100, Sascha Wilde wrote: >> Hi *, >> >> The problem is most noticeable when a user shares his INBOX[0][1] with >> others: >> >> User A sets his INBOX acls to "eilprwtsd" >> >> Now User B can see _all_ sub mailboxes and sub sub [...] mailboxes and >> their contents of User A: > > That shouldn't happen. There's no code for doing recursive ACLs. Sounds > more like a bug somewhere. I'll check it later. Thanks. >> * ACL "INBOX" "a...@example.com" akxeilprwtscd "b...@example.com" >> eilprwtsd "a...@example.com" lrwstipekxacd > > a...@example.com is there twice?.. Oh, haven't noticed that, but yes its actually there twice. The dovecot-acl file contains: use...@example.com akxeilprwts use...@example.com eilprwts >> * LIST (\HasChildren) "/" "user/1...@aztec.intevation.de/foobar" > > How does user B see this mailbox's ACLs? Is the mailbox also selectable? Well good question -- unfortunately I can't tell: both getacl and myrights on "user/1...@aztec.intevation.de/foobar" make the imap process die on SIGV... :-( cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgp70TpCvjysr.pgp Description: PGP signature
[Dovecot] v1.2: can't access other users shared INBOX
Hi *, when a user A shares his INBOX with another user B, the user B can't access its content: User A: g getacl INBOX * ACL INBOX a...@example.com lrswipkxtecda b...@example.com lrswipkxtecd g OK Completed User B: l list "" "*" * LIST (\Noselect \HasChildren) "/" "user" * LIST (\Noselect \HasChildren) "/" "user/a...@example.com" * LIST (\HasChildren) "/" "INBOX" * LIST (\HasNoChildren) "/" "INBOX/Gesendet" * LIST (\HasChildren) "/" "user/a...@example.com/foobar" * LIST (\HasNoChildren) "/" "user/a...@example.com/INBOX" l OK List completed. s1 select "user/a...@example.com" s1 NO [CANNOT] Invalid mailbox name s2 select "user/a...@example.com/INBOX" s2 NO [NONEXISTENT] Mailbox doesn't exist: INBOX Actually there are two bugs to observe here: 1) "user/a...@example.com" really should be accessible to user B. Why is it listed with "\Noselect"? 2) "user/a...@example.com/INBOX" does not exist, so the error message is correct, but why does it appear in the listing in the first place? cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpj2KaWNC3Bd.pgp Description: PGP signature
Re: [Dovecot] ACLs are applied recursively to sub mailboxes
Sascha Wilde writes: Ooops some search and replace missing, the example should read: > User A: > g getacl INBOX > * ACL "INBOX" "a...@example.com" akxeilprwtscd "b...@example.com" eilprwtsd > "a...@example.com" lrwstipekxacd > g OK Getacl completed. > g getacl INBOX/foobar > * ACL "INBOX/foobar" "a...@example.com" lrwstipekxacd > > User B: > l list "" "*" > * LIST (\Noselect \HasChildren) "/" "user" > * LIST (\Noselect \HasChildren) "/" "user/a...@example.com" > * LIST (\HasChildren) "/" "INBOX" > * LIST (\HasNoChildren) "/" "INBOX/Gesendet" > * LIST (\HasChildren) "/" "user/a...@example.com/foobar" > * LIST (\HasNoChildren) "/" "user/a...@example.com/foobar/barbaaz" > * LIST (\HasNoChildren) "/" "user/a...@example.com/INBOX" > l OK List completed. cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpY0KDxECF5C.pgp Description: PGP signature
[Dovecot] ACLs are applied recursively to sub mailboxes
Hi *, The problem is most noticeable when a user shares his INBOX[0][1] with others: User A sets his INBOX acls to "eilprwtsd" Now User B can see _all_ sub mailboxes and sub sub [...] mailboxes and their contents of User A: User A: g getacl INBOX * ACL "INBOX" "a...@example.com" akxeilprwtscd "b...@example.com" eilprwtsd "a...@example.com" lrwstipekxacd g OK Getacl completed. g getacl INBOX/foobar * ACL "INBOX/foobar" "1...@aztec.intevation.de" lrwstipekxacd User B: l list "" "*" * LIST (\Noselect \HasChildren) "/" "user" * LIST (\Noselect \HasChildren) "/" "user/1...@aztec.intevation.de" * LIST (\HasChildren) "/" "INBOX" * LIST (\HasNoChildren) "/" "INBOX/Gesendet" * LIST (\HasChildren) "/" "user/1...@aztec.intevation.de/foobar" * LIST (\HasNoChildren) "/" "user/1...@aztec.intevation.de/foobar/barbaaz" * LIST (\HasNoChildren) "/" "user/1...@aztec.intevation.de/INBOX" l OK List completed. The RfC is not to verbose on this topic of scope, but I think the following excerpt from RfC4314: 2. Access Control [...] An access control list is a set of pairs. An ACL applies to a mailbox name. indicates that ACLs are only valid for individual mailboxes (name) and not for sub mailboxes. cheers sascha [0] Yes, there are really actual users wanting to do this. [1] There is actually another bug in this context I'll report in my next mail... -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpXWJPCkmElf.pgp Description: PGP signature
Re: [Dovecot] Shared mailbox documentation updated
Timo Sirainen writes: > http://wiki.dovecot.org/SharedMailboxes Great! > Anything missing? Anything still need clarifying? On a first glance looks looks quite complete. :) Maybe the configuration example should include "mail_location" to show how it relates to the "location" in the shared name space definition. But that's just a minor suggestion. sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpqsl8KlQEBA.pgp Description: PGP signature
Re: [Dovecot] v1.2.beta1 released
Timo Sirainen writes: > On Thu, 2009-02-12 at 13:10 +0100, Sascha Wilde wrote: >> - cyrus imapd actually tries[1] to implement a variant of this >> possibility in that it does not allow to remove the 'a' right from the >> owner: > > I implemented this to Dovecot now too. Good. :) I just gave it a try. I was a little worried when I saw that I was able to remove all admin rights from an folder by giving "a" to another user and let this user first remove "a" from the owner and then from him self -- fortunately the owner was still able to edit the acls (despite the missing administrator flag.), so everything is fine: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN] Dovecot ready. lo login bar secret lo OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT THREAD=REFERENCES MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH ACL RIGHTS=texk ANNOTATEMORE] Logged in li list "" "*" * LIST (\Noselect \HasChildren) "/" "user" * LIST (\Noselect \HasChildren) "/" "user/f...@example.com" * LIST (\HasChildren) "/" "INBOX" * LIST (\HasNoChildren) "/" "user/f...@example.com/test-share" li OK List completed. g getacl "user/f...@example.com/test-share" * ACL "user/f...@example.com/test-share" "f...@example.com" akxeilprwtscd "b...@example.com" akxeilprwtscd g OK Getacl completed. s setacl "user/f...@example.com/test-share" "f...@example.com" -a s OK Setacl complete. g getacl "user/f...@example.com/test-share" * ACL "user/f...@example.com/test-share" "f...@example.com" kxeilprwtscd "b...@example.com" akxeilprwtscd g OK Getacl completed. s setacl "user/f...@example.com/test-share" "b...@example.com" kxeilprwtscd s OK Setacl complete. getacl "user/f...@example.com/test-share" getacl BAD Error in IMAP command "USER/f...@example.com/TEST-SHARE": Unknown command. lo logout * BYE Logging out lo OK Logout completed. * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN] Dovecot ready. loginb foo secret loginb BAD Error in IMAP command received by server. lo login elf 11 lo OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT THREAD=REFERENCES MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH ACL RIGHTS=texk ANNOTATEMORE] Logged in li list "" "*" * LIST (\HasChildren) "/" "INBOX" * LIST (\HasNoChildren) "/" "INBOX/test-share" li OK List completed. g getacl "INBOX/test-share" * ACL "INBOX/test-share" "f...@example.com" kxeilprwtscd "b...@example.com" kxeilprwtscd g OK Getacl completed. s setacl "INBOX/test-share" "f...@example.com" +a s OK Setacl complete. g getacl "INBOX/test-share" * ACL "INBOX/test-share" "f...@example.com" akxeilprwtscd "b...@example.com" kxeilprwtscd g OK Getacl completed. I'm not sure if every detail here is intended, but I think its an good solution. >> > I think the owner ACLs are usually in global ACL files, so >> > it's probably not possible to remove or change it, only add a new >> > user=x. >> >> I think that it would be best to always map the owners user name to >> the keyword "owner" and vice versa between the IMAP front end and the >> acl back end. This way user=x where x is the owners user name should >> never appear in an dovecot-acl file. > > I did consider this too, but then I thought that it could cause wrong > results in some special situations. For example if another user's > mailbox is symlinked to your private namespace and you change your own > rights, it really should change them and not the owner's. I haven't thought of that. I agree that in such cases the mapping would fail. However I think there are many setups where such symlink hacks are not used (and I guess with the new shared user namespaces and IMAP ACL front end there will be even fewer cases in which such tricks are useful) -- so maybe this could be configure able? >> So it boils down to the question >> if the individual acl-files should take precedence over the global one >> -- without having checked I assume this decision already has been made. > > IIRC in v1.1 mailbox ACL files take precedence, but in v1.2 globals take > precedence. I changed it because users shouldn't be able to override > admin's decisions. I g
Re: [Dovecot] IMAP ACLs and global ACLs in v1.2
Timo Sirainen writes: > On Thu, 2009-01-15 at 17:48 +0100, Sascha Wilde wrote: >> > But should it just internally convert "owner" to "username" when >> > replying? >> >> From our experience this would be a very good idea. Many clients >> recognize the username and handle those ACLs differently in there UI >> (for example they don't offer them for editing). But they don't >> understand "owner". > > GETACL now converts owner to username when ACLs contain owner right, but > no username right. Great, thanks. A quick test looks perfect. :) cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpHOSauZhHxd.pgp Description: PGP signature
[Dovecot] v1.2 can't set ACL to empty string
Hi *,
according to RfC4314 the rights argument to the setacl command might be
an empty string ("zero right characters"):
The third argument is a string containing an optional plus ("+") or
minus ("-") prefix, followed by zero or more rights characters.
existing clients (horde in particular) actually use this to remove all
rights from an user.
Currently dovecot 1.2 does not accept an empty rights string as argument
to setacl. Bernhard Herzog will look into this.
cheers
sascha
--
Sascha Wilde OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/ http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
pgpYLTBvXUm4n.pgp
Description: PGP signature
Re: [Dovecot] IMAP ACLs and global ACLs in v1.2
Robert Schetterer writes: > Sascha Wilde schrieb: >> Robert Schetterer writes: >>> Bernhard Herzog schrieb: >>>> On 15.01.2009, Sascha Wilde wrote: >>>>>> But should it just internally convert "owner" to "username" when >>>>>> replying? >>>>> From our experience this would be a very good idea. Many clients >>>>> recognize the username and handle those ACLs differently in there UI >>>>> (for example they don't offer them for editing). But they don't >>>>> understand "owner". >>>> To work around this, we created a patch that tries to avoid the owner ACL >>>> entries. >> [...] >>> i dont think you should mess around what clients think >>> where should this end , the technical right and most clear description >>> is owner, username can be very wide interpreted and may lead >>> to technical problems in reading imap-acl i.e from horde imp or other >>> mail clients later, as far i remember owner is use i.e in exchange too >> I'm not quite sure if we are talking about the same thing. This is >> about the reply to the getacl command in the imap protocol (in opposite >> to the output in the clients UI). > > i was talking about imap getacl, which answers owner Me too. [...] >> I don't know about exchange, but most clients don't know about dovecots >> special meaning of "owner" but simply consider it an ordinary user name. > > do you mean clients as humans or mail clients? Mail clients == software speaking IMAP aware of the IMAP ACL extension. [...] > whatever what i mean was leave the code to standarts I agree, and we do. Problem is, while not prohibited by the standard keywords like "owner" are not defined by the standard. Even worse: there is no way in IMAP ACL to distinct such special keywords from actual user names. Please see the first footnote in my latest mail in the thread "v1.2.beta1 released" Message-ID: for more details. cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpRll302cpqS.pgp Description: PGP signature
Re: [Dovecot] v1.2: Can't subscribe to shared user folder
Timo Sirainen writes: > On Wed, 2009-02-11 at 11:04 +0100, Sascha Wilde wrote: >> a003 subscribe "user/b...@example.com/foobar" >> a003 NO Unknown subscription namespace. > > What kind of namespace configuration do you have? This sounds like your > shared namespace has subscriptions=no, but you don't have a namespace > with empty prefix that has subscriptions=yes. You are right we added a prefix to the primary private namespace recently, adding subscriptions=yes to the shared namespace definition solves it. I should have had a look at the current config before complaining -- sorry for the noise. :( cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgp32k423ARhJ.pgp Description: PGP signature
Re: [Dovecot] v1.2.beta1 released
Timo Sirainen writes: > On Wed, 2009-02-11 at 11:00 +0100, Sascha Wilde wrote: >> Could we by any chance get the latest small changes/enhancements: >> - 'c' and 'd' in setacl > > Yes, this will definitely be included. This is very good news. >> - Displaying the actual user name instead of meta name "owner" on getacl >> output (see Bernhards patch in the "IMAP ACLs and global ACLs in v1.2" >> thread) > That patch appears to be also changing owners to user=x? This is indeed quite possible -- I haven't seen it happen in my tests though... As Bernhard wrote him self on the patch: we are not sure it is the right solution -- actually he is pretty sure it isn't ... ;-) > I wouldn't mind a patch that showed them to clients as user=x, but I > don't want them to change when something else gets changed. For us[0] changing what is shown to the client is sufficient. Actually on a second thought I agree with you, that keeping the special owner keyword internally is preferable. > Also I'm not entirely sure how it should be handled when user=x ACL is > changed. Should it remove the owner? Should it change the owner > instead? This is a good point. IMO there are only a couple of possibilities: - we could define that only the server-administrator is allowed to change owner acls by means of setting global acls or manually editing the dovecot-acl files. Rational: Users shouldn't be able to change the owners acls, to prevent them from shooting there own foots. In this case changing the acl for the user which maps to "owner" would be silently ignored. - cyrus imapd actually tries[1] to implement a variant of this possibility in that it does not allow to remove the 'a' right from the owner: s setacl INBOX/foo 1...@burlywood1.rgb lrswipkxtecd s OK Completed g getacl INBOX/foo * ACL INBOX/foo 1...@burlywood1.rgb lrswipkxtecda g OK Completed s setacl INBOX/foo 1...@burlywood1.rgb lrs s OK Completed g getacl INBOX/foo * ACL INBOX/foo 1...@burlywood1.rgb lrskxca I think this is worth considering. - Allow everything allowed by the actual ACLs, so every user having a(dmin) rights is free to change all ACLs even if it leads to folders where no user has the right to change it any more. Rational: unix philosophy, obey to user demands and don't be nuisance, shooting ones own foot is a basic freedom... ;-) > I think the owner ACLs are usually in global ACL files, so > it's probably not possible to remove or change it, only add a new > user=x. I think that it would be best to always map the owners user name to the keyword "owner" and vice versa between the IMAP front end and the acl back end. This way user=x where x is the owners user name should never appear in an dovecot-acl file. So it boils down to the question if the individual acl-files should take precedence over the global one -- without having checked I assume this decision already has been made. cheers sascha [0] Actually IMNSHO this subject is not only relevant to us: - The acl aware clients I know of don't recognize the special meaning of "owner". - This makes perfect sense, as there is no specified way to decide if the string "owner" in an IMAP ACL reply denotes an user actually named owner or is an special keyword denoting "the user owning the folder". - Finally, even if an client would recognize "owner" as an special keyword, it wouldn't be able to figure out who the owner actual is. Which makes the information of rather low use. [1] I just tested some scenarios and it turned out they messed up on the details, so that one can actually end up with an folder which no user has admin rights one and the output of myrights and getacl is inconsistent -- quite funny! -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgp8luaDoKtPO.pgp Description: PGP signature
Re: [Dovecot] Understanding dovecot ACLs
Achim Hut writes: [...] > What i need is a scenario, where user1 can get (for example) full > access to the folders of user2, read-only access to user3 etc. > A real world example: > Secretary has full access to the mailfolders of her boss, boss has > read-only acces to the sales-department folder. Full support for shared user folders (like in your example) is a new feature in the upcoming dovecot 1.2 release. It might be possible to hack up what you need with dovecot 1.1.x but I'd say it isn't worth the trouble -- instead I'd recommend to beta-test 1.2. :-) cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgp2MF1Ohfiyu.pgp Description: PGP signature
[Dovecot] v1.2: Can't subscribe to shared user folder
Hi *, I stumbled across a small bug (missing feature?) in the new shared name space stuff: a001 list "" "*" * LIST (\Noselect \HasChildren) "/" "user" * LIST (\Noselect \HasChildren) "/" "user/b...@example.com" * LIST (\HasChildren) "/" "INBOX" * LIST (\HasNoChildren) "/" "INBOX/bar" * LIST (\HasNoChildren) "/" "user/b...@example.com/brooklebookle" * LIST (\HasNoChildren) "/" "user/b...@example.com/foobar" a001 OK List completed. a002 lsub "" "*" a002 OK Lsub completed. a003 subscribe "user/b...@example.com/foobar" a003 NO Unknown subscription namespace. I'm quite sure this once worked in our original code (but of cause I could be mistaken). cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpOGtYG01wn7.pgp Description: PGP signature
Re: [Dovecot] v1.2.beta1 released
Timo Sirainen writes: > http://dovecot.org/releases/1.2/beta/dovecot-1.2.beta1.tar.gz > http://dovecot.org/releases/1.2/beta/dovecot-1.2.beta1.tar.gz.sig Great news! :-) [...] > There isn't really much left to do for v1.2.0 except some small fixing > to shared mailbox code. And writing documentation for it.. Could we by any chance get the latest small changes/enhancements: - 'c' and 'd' in setacl - Displaying the actual user name instead of meta name "owner" on getacl output (see Bernhards patch in the "IMAP ACLs and global ACLs in v1.2" thread) in 1.2? I know it's a little late but I think that would greatly extend the compatibility with existing clients -- and would enable us to use the current upstream dovecot without any changes ... ;) Oh and one more thing, I just discovered another small problem: one can't subscribe to shared user folders. I'll put the report in a new mail. cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpzoISWy1j7L.pgp Description: PGP signature
Re: [Dovecot] [patch] 'c' and 'd' in setacl
Hi Timo,
thanks for your reply!
Timo Sirainen writes:
> On Fri, 2009-02-06 at 12:29 +0100, Sascha Wilde wrote:
>> I just recognized that the new imap-acl plugin in dovecot 1.2 does not
>> know the obsolete rights 'd' and 'c' when setting.
> ..
>> [0] I don't like the use of static indexes witch imap_acl_letter_map but
>> currently I wasn't able to decide on a more elegant solution.
>
> How about instead of
>
> array_append(rights, &imap_acl_letter_map[8].name
>
> something like:
>
> str = MAIL_ACL_CREATE;
> array_append(rights, &str
I gave it a try in the attached patch. Actually I considered that my
self but I'm (still) not sure if this is 100% legal according to the
standard.
Partly this is because I haven't fully understood which information from
the array "rights" is retained outside the function (by means of
"rights_r"). Partly its because I'm not sure if it's ok to refer to the
immediate string value used to initialize an automatic variable outside
the function.
In case you are sure the attached version is kosher I would indeed like
it better than the first.
cheers
sascha
--
Sascha Wilde OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/ http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
diff -r df8bcff0ee01 src/plugins/imap-acl/imap-acl-plugin.c
--- a/src/plugins/imap-acl/imap-acl-plugin.c Thu Feb 05 11:17:35 2009 +0100
+++ b/src/plugins/imap-acl/imap-acl-plugin.c Mon Feb 09 12:22:31 2009 +0100
@@ -303,6 +303,10 @@
{
ARRAY_TYPE(const_string) rights;
unsigned int i;
+ static const char *acl_k = MAIL_ACL_CREATE;
+ static const char *acl_x = MAIL_ACL_DELETE;
+ static const char *acl_e = MAIL_ACL_EXPUNGE;
+ static const char *acl_t = MAIL_ACL_WRITE_DELETED;
t_array_init(&rights, 64);
for (; *letters != '\0'; letters++) {
@@ -314,9 +318,22 @@
}
}
if (imap_acl_letter_map[i].name == NULL) {
- *error_r = t_strdup_printf("Invalid ACL right: %c",
- *letters);
- return -1;
+ /* Handling of obsolete rights as virtual
+ * rights according to RFC 4314 */
+ switch (*letters) {
+ case 'c':
+array_append(&rights, &acl_k, 1);
+array_append(&rights, &acl_x, 1);
+break;
+ case 'd':
+array_append(&rights, &acl_e, 1);
+array_append(&rights, &acl_t, 1);
+break;
+ default:
+*error_r = t_strdup_printf("Invalid ACL right: %c",
+ *letters);
+return -1;
+ }
}
}
(void)array_append_space(&rights);
pgpu5IqqFyVyR.pgp
Description: PGP signature
[Dovecot] [patch] 'c' and 'd' in setacl
Hi Timo,
Hi *,
I just recognized that the new imap-acl plugin in dovecot 1.2 does not
know the obsolete rights 'd' and 'c' when setting. According to RFC
4314 section 2.1.1.:
If a client includes the "d" right in a rights list, then it MUST be
treated as if the client had included every member of the "delete"
right.
and
If a client includes the "c" right in a rights list, then it MUST be
treated as if the client had included every member of the "create"
right.
Unfortunatly there are actually clients which depend on this behavior.
I attached a rather rough[0] patch which implements this.
cheers
sascha
[0] I don't like the use of static indexes witch imap_acl_letter_map but
currently I wasn't able to decide on a more elegant solution.
--
Sascha Wilde OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/ http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
changeset: 8724:58e9edcb4311
branch: HEAD
tag: tip
user:Sascha Wilde
date:Fri Feb 06 12:16:10 2009 +0100
files: src/plugins/imap-acl/imap-acl-plugin.c
description:
imap-acl: Added handling of virtual rights `d' and `c'.
diff -r df8bcff0ee01 -r 58e9edcb4311 src/plugins/imap-acl/imap-acl-plugin.c
--- a/src/plugins/imap-acl/imap-acl-plugin.c Thu Feb 05 11:17:35 2009 +0100
+++ b/src/plugins/imap-acl/imap-acl-plugin.c Fri Feb 06 12:16:10 2009 +0100
@@ -314,9 +314,26 @@
}
}
if (imap_acl_letter_map[i].name == NULL) {
- *error_r = t_strdup_printf("Invalid ACL right: %c",
- *letters);
- return -1;
+ /* Handling of obsolete rights as virtual
+ * rights according to RFC 4314 */
+ switch (*letters) {
+ case 'c':
+array_append(&rights,
+ &imap_acl_letter_map[8].name, 1); /* k */
+array_append(&rights,
+ &imap_acl_letter_map[9].name, 1); /* x */
+break;
+ case 'd':
+array_append(&rights,
+ &imap_acl_letter_map[7].name, 1); /* e */
+array_append(&rights,
+ &imap_acl_letter_map[4].name, 1); /* t */
+break;
+ default:
+*error_r = t_strdup_printf("Invalid ACL right: %c",
+ *letters);
+return -1;
+ }
}
}
(void)array_append_space(&rights);
pgpzGlIeoX6tb.pgp
Description: PGP signature
Re: [Dovecot] IMAP ACLs and global ACLs in v1.2
Robert Schetterer writes: > Bernhard Herzog schrieb: >> On 15.01.2009, Sascha Wilde wrote: >>>> But should it just internally convert "owner" to "username" when >>>> replying? >>> From our experience this would be a very good idea. Many clients >>> recognize the username and handle those ACLs differently in there UI >>> (for example they don't offer them for editing). But they don't >>> understand "owner". >> >> To work around this, we created a patch that tries to avoid the owner ACL >> entries. [...] > i dont think you should mess around what clients think > where should this end , the technical right and most clear description > is owner, username can be very wide interpreted and may lead > to technical problems in reading imap-acl i.e from horde imp or other > mail clients later, as far i remember owner is use i.e in exchange too Hi Robert, I'm not quite sure if we are talking about the same thing. This is about the reply to the getacl command in the imap protocol (in opposite to the output in the clients UI). I don't know about exchange, but most clients don't know about dovecots special meaning of "owner" but simply consider it an ordinary user name. On the other hand I know horde imp (the Kolab Webclient is horde based) and I can assure you that it gets confused by dovecots current behavior: it does not recognize "owner" as "the actual owner of that mailbox" and does not handle the ACL in any special way while it _does_ recognize when the returned username is matching the current user and for instance horde prevents the user from changing his own right. Further more there is no way in the IMAP ACL extension to determine the "owner" of an mailbox I'm aware of, so there would be no way for an client to resolve the "owner" ACL to an actual user, which makes the information rather useless. cheers -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpMHBKG6grje.pgp Description: PGP signature
[Dovecot] Segfault in deliver server
Hi Timo,
Hi list,
I finally got along to test the current dovecot 1.2 with our Kolab
Server. And I'm very excited to see all the cool ACL and shared
name spaces stuff upstream, thanks a lot Timo!
Anyway I just stumbled across a new bug using our metadata-plugin (which
in turn uses the dict back end):
Making a few annotations requests after another it stops working.
dovecot.log sais something like:
Feb 03 11:58:21 burlywood3 dovecot[10486]: IMAP(4...@burlywood3.rgb):
metadata_get_metadata_entry: dict
key=shared//kolab/var/dovecot/spool/4...@burlywood3.
rgb/home/maildir/.Calendar//vendor/kolab/folder-type
Feb 03 11:58:21 burlywood3 dovecot[10486]: child 10503 (dict) killed
with signal 11
Feb 03 11:58:21 burlywood3 dovecot[10486]: IMAP(4...@burlywood3.rgb):
read(/kolab/var/dovecot/run/dict-server) failed: Connection reset by peer
Feb 03 11:58:21 burlywood3 dovecot[10520]: Fatal: dup2(3) failed:
Bad file descriptor
Feb 03 11:58:21 burlywood3 dovecot[10486]: child 10520 (dict) returned
error 89 (Fatal failure)
Feb 03 11:58:21 burlywood3 dovecot[10486]: Panic: file ioloop.c:
line 38 (io_add): assertion failed: (fd >= 0)
(END)
I attached gdb to dict and got this:
Program received signal SIGSEGV, Segmentation fault.
array_idx_modifiable_i (array=0x38, idx=0) at array.c:10
10 pos = idx * array->element_size;
(gdb) bt
#0 array_idx_modifiable_i (array=0x38, idx=0) at array.c:10
#1 0x0805e9a2 in sql_pool_unlink (ctx=0x80fb670) at sql-pool.c:64
#2 0x0805ea24 in sql_pool_new (pool=0x80f9470, db_driver=0x80dd498 "sqlite",
connect_string=0x810ad78 "/kolab/var/dovecot/lib/metadata-dict.sqlite")
at sql-pool.c:97
#3 0x0805bb3c in sql_dict_init (driver=0x80f9ae0, uri=0xbfce9f76
"/kolab/etc/dovecot/metadata-dict.conf", value_type=DICT_DATA_TYPE_STRING,
username=0x80fb910 "4...@burlywood3.rgb") at dict-sql.c:86
#4 0x0805c9ca in dict_init (uri=0xbfce9f6f
"sqlite:/kolab/etc/dovecot/metadata-dict.conf",
value_type=DICT_DATA_TYPE_STRING,
username=0x80fb910 "4...@burlywood3.rgb") at dict.c:87
#5 0x0805a1b1 in dict_client_connection_input (conn=0x80fb8d0) at
dict-server.c:407
#6 0x0806637c in io_loop_handler_run (ioloop=0x80f8a80) at ioloop-epoll.c:202
#7 0x080652fd in io_loop_run (ioloop=0x80f8a80) at ioloop.c:338
#8 0x0805a42d in main () at main.c:122
(gdb) li
5
6 void *array_idx_modifiable_i(struct array *array, unsigned int idx)
7 {
8 size_t pos;
9
10 pos = idx * array->element_size;
11 if (pos >= array->buffer->used) {
12 /* index doesn't exist yet, initialize with zero */
13 buffer_append_zero(array->buffer, pos +
array->element_size -
14 array->buffer->used);
(gdb) p array
$1 = (struct array *) 0x38
(gdb) p *array
Cannot access memory at address 0x38
(gdb) up
#1 0x0805e9a2 in sql_pool_unlink (ctx=0x80fb670) at sql-pool.c:64
64 next_ctx = SQL_POOL_CONTEXT(ctx->prev);
(gdb) p *ctx
$2 = {module_ctx = {reg = 0x0}, prev = 0x0, next = 0x810d2b0, pool = 0x80f9470,
refcount = 0,
key = 0x80fb638 "sqlite\t/kolab/var/dovecot/lib/metadata-dict.sqlite",
orig_deinit = 0x805f229 }
(gdb) li
59 prev_ctx->next = ctx->next;
60 }
61 if (ctx->next == NULL)
62 ctx->pool->unused_head = ctx->prev;
63 else {
64 next_ctx = SQL_POOL_CONTEXT(ctx->prev);
65 next_ctx->prev = ctx->prev;
66 }
67 ctx->pool->unused_count--;
68 }
(gdb) c
Continuing.
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists
It's quite possible, that we got any details in the usage of the dict
back end wrong, but I guess that in any case the dict server shouldn't
segfault...
cheers
sascha
--
Sascha Wilde OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/ http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
pgpUfAMhvNrLd.pgp
Description: PGP signature
Re: [Dovecot] IMAP ACLs and global ACLs in v1.2
Hi Timo, Hi List, It's been a while since our last post (talking for "the Kolab guys" here). Sorry for that but we were very busy on various subjects -- and Christmas, New-year and all that exhausting holidays ... ;-) I'm very happy to see all the features needed by Kolab integrated in 1.2. Unfortunately I wasn't able to give it some thorough testing, yet ... but I really hope to find the time to do so soon, so that we can migrate our work on Kolab+Dovecot to the current 1.2 head. Timo Sirainen writes: [...] > One thing I'm not really sure about is the "owner" handling. IMAP ACL > specifications have no such concept. I think many/most other servers > simply add a default ACL for the user name directly. It's a useful > concept though, especially with the global ACLs. So currently Dovecot > replies: > > x getacl inbox > * ACL "inbox" "owner" lrwstiekxacd > x OK Getacl completed. > > But should it just internally convert "owner" to "username" when > replying? From our experience this would be a very good idea. Many clients recognize the username and handle those ACLs differently in there UI (for example they don't offer them for editing). But they don't understand "owner". > But then again if there's a separate rule directly for the "username" > it breaks. I think this would be primarily show an configuration or migration problem. Maybe "owner" should take precedence over those rules? In general I think, that in an sane setup only the owner rule should exist and when it maps to the username in the IMAP front end the should be no way to existentially create seperate rules for the owners username. cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpOhMuBDcosO.pgp Description: PGP signature
Re: [Dovecot] New %%h variable for shared namespaces
Sascha Wilde <[EMAIL PROTECTED]> writes: > Timo Sirainen <[EMAIL PROTECTED]> writes: >> On Fri, 2008-10-31 at 17:12 +0200, Timo Sirainen wrote: >>> > See >>> > http://hg.intevation.org/kolab/dovecot-1.2_kolab-branch/rev/e83efa40a1dc >>> >>> The auth connection could be kept alive longer than for one lookup if >>> you put the auth_connection to shared_storage. That'd require creating >>> struct shared_storage, but it should be pretty easy (see e.g. struct >>> cydir_storage or maildir_storage). >> >> Actually shared_storage already existed, somehow I missed that. Anyway I >> did the things I mentioned and some other stuff and committed it. > > Thanks a lot! > > I'll test it in our environment... Works like charm -- at least in the few tests I did... cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpEubB1P4H6m.pgp Description: PGP signature
Re: [Dovecot] New %%h variable for shared namespaces
Timo Sirainen <[EMAIL PROTECTED]> writes: > On Fri, 2008-10-31 at 17:12 +0200, Timo Sirainen wrote: >> > See >> > http://hg.intevation.org/kolab/dovecot-1.2_kolab-branch/rev/e83efa40a1dc >> >> The auth connection could be kept alive longer than for one lookup if >> you put the auth_connection to shared_storage. That'd require creating >> struct shared_storage, but it should be pretty easy (see e.g. struct >> cydir_storage or maildir_storage). > > Actually shared_storage already existed, somehow I missed that. Anyway I > did the things I mentioned and some other stuff and committed it. Thanks a lot! I'll test it in our environment... Cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpAPGI5Fiisc.pgp Description: PGP signature
Re: [Dovecot] New %%h variable for shared namespaces (was: New generic userdb lookup api)
Sascha Wilde <[EMAIL PROTECTED]> writes:
> Ok, as discussed I have made some changes (hopefully improvements) in
> the new "auth-master" API for userdb requests...
And using this new I finally put a first alpha version of the missing
%%h variable for shared name spaces together.
See http://hg.intevation.org/kolab/dovecot-1.2_kolab-branch/rev/e83efa40a1dc
With this it is possible to define a name space like this:
namespace shared {
separator = /
prefix = users/%%u/
location = Maildir:/%%h/maildir
subscriptions = no
}
where %%h is substituted with the home directory of user %%u, which is
needed e.g. when the mail location is configured as:
mail_location = maildir:~/maildir
cheers
sascha
--
Sascha Wilde OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/ http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
pgpPGEmsU0sjv.pgp
Description: PGP signature
Re: [Dovecot] New generic userdb lookup api
Ok, as discussed I have made some changes (hopefully improvements) in the new "auth-master" API for userdb requests... Sascha Wilde <[EMAIL PROTECTED]> writes: > Timo Sirainen <[EMAIL PROTECTED]> writes: [...] >> 3. Would be nice to get rid of the getenv()s :) The MAIL_CHROOT handling >> could be moved to deliver (use it if reply->chroot == NULL). The debug >> could be a parameter to auth_master_init(). > > You are right, and as I moved/left most of the env stuff in > deliver/auth-client anyway it is only consequent to handle those two the > same -- I'll make this change. Done, the last getenv()s have been moved to the deliver code. >> 4. You're leaking memory. > > Um, yes. *blush* -- at least I added the free for the connection shortly > after my announcement... ;-) > >> Cleanest fix would be to add pool_t pool parameter to >> auth_master_user_lookup() and allocate memory only from it Done. I thought for a moment of putting the pool (de)allocation into auth_master_init and auth_master_deinit -- but that turned out to be to quirky, especially with the existing deliver code... >> (also p_array_init(&reply->extra_fields) would be cleaner to do inside >> the lookup code than require it to be done externally). Done, too. cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpvwa2nMJGw7.pgp Description: PGP signature
Re: [Dovecot] New generic userdb lookup api
Timo Sirainen <[EMAIL PROTECTED]> writes:
>>> The idea behind Dovecot's memory allocations is that you shouldn't
>>> have
>>> to go through all the trouble of doing lots of memory
>>> frees. Because 1)
>>> it's easy to cause memory leaks then, 2) it requires more code and
>>> makes
>>> it uglier, 3) possibly increases memory fragmentation.
>>>
>>> So with memory pools you just allocate all the memory from the pool
>>> and
>>> finally simply free the pool. That takes care of all these 1-3)
>>> issues.
>>> It could use slightly more memory, but especially for these kind of
>>> short living allocations it really doesn't matter.
>>
>> Than I don't really see the problem with the current code -- I
>> understand that all the memory it uses (with i_strdup and friends) is
>> allocated from the default pool, which I assume will be freed
>> eventually.
>
> Well, "default pool" isn't really a proper memory
> pool. p_malloc(default_pool) = p_malloc(system_pool) = i_malloc() =
> calloc(). It will only get freed when the process is killed.
Hmm, that would be after the end of the imap connection (deliver should
be no problem anyway) -- yes this could indeed take some time...
>> If the goal of an dedicated pool is to free the memory early the code
>> using the auth-master API will have to allocate and free this pool, I
>> don't see the advantage here... But then, on a second thought I _do_
>> see the advantage of a consistent way to do things like this. ;-)
>
> I was thinking something like:
>
> pool = pool_alloconly_create("userdb lookup", 512);
> auth_master_lookup(auth, pool, &reply);
> // do stuff with reply
> pool_unref(&pool);
> Or I suppose auth_master_init() could allocate the pool internally and
> call p_clear() at the beginning of each lookup. Hmm.
I think I prefer the first version, as in the second proposal replies
From older lookups would become destroyed with every new lookup, which
IMO would not be really evident to the user of the API.
>>>> Btw, on dedicated vs. default resources, I wasn't quite sure if it
>>>> was a
>>>> good idea to use the default ioloop. Any thoughts on that?
>>>
>>> For deliver it doesn't matter, but for imap you really should
>>> create a
>>> new ioloop or things will probably break.
>>
>> Yes, I know (already made this mistake)... ;-)
>> The question is, should the ioloop be an extra argument to
>> auth_master_init?
>
> I don't think there's any benefit in doing that.
Ok, thanks for your input. :)
I'll put together an a little improved version this afternoon.
cheers
sascha
--
Sascha Wilde OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/ http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
pgpyFcOOmeNVC.pgp
Description: PGP signature
Re: [Dovecot] New generic userdb lookup api
Timo Sirainen <[EMAIL PROTECTED]> writes: > On Sun, 2008-10-26 at 18:33 +0100, Sascha Wilde wrote: >> Timo Sirainen <[EMAIL PROTECTED]> writes: >> > On Fri, 2008-10-24 at 16:19 +0200, Sascha Wilde wrote: >> >> Ok, I used auth-master.* -- the new code is in changeset f5ce17153a3d in >> >> my kolab-branch at >> >> http://hg.intevation.org/kolab/dovecot-1.2_kolab-branch/ and I made >> >> deliver use it in 94b00e377a25. >> >> >> >> I had no time for thorough testing, but in my test-setup it seems to >> >> work like before, so at least I didn't break it completely... ;-) >> > >> > A couple of things: >> > >> > 1. It disconnects after each lookup. Not good if multiple lookups are >> > done. Then again it probably shouldn't keep the connection alive forever >> > since the imap connections can run for ages and most of the necessary >> > lookups are probably done close to each others. Maybe timeout after 1 >> > minute of idling? >> >> I agree that this is something that should be optimized, but I was under >> the impression, that the current behavior of deliver was just like that >> -- maybe I'm mistaken, I haven't double-checked that... > > deliver does always only one lookup, so it doesn't matter. But for IMAP > if you have shared mailboxes from multiple users it'll do multiple > lookups. Ack. >> > 2. conn->to is for auth request timeout. It should be removed after >> > io_loop_run() so if 1. is fixed it won't leak timeouts. >> > (The same conn->to could actually be used for the two timeouts - one >> > value when looking up, another value when idling.) >> >> Ack. Unfortunately I'll have to put a working prototype of the >> "%%h"-feature together before I'll have time to look into that... > > Well, I could probably get these missing things done too. This would be really great and highly appreciated! I just didn't dare to ask... :-) >> > Cleanest fix would be to add pool_t pool parameter to >> > auth_master_user_lookup() and allocate memory only from it >> >> I think a free_auth_user_reply function might be preferable. >> >> But I have to admit, that I didn't look deeply enough into the memory >> pool management in dovecot to really know whats The Right Thing To >> Do[tm]. > > The idea behind Dovecot's memory allocations is that you shouldn't have > to go through all the trouble of doing lots of memory frees. Because 1) > it's easy to cause memory leaks then, 2) it requires more code and makes > it uglier, 3) possibly increases memory fragmentation. > > So with memory pools you just allocate all the memory from the pool and > finally simply free the pool. That takes care of all these 1-3) issues. > It could use slightly more memory, but especially for these kind of > short living allocations it really doesn't matter. Than I don't really see the problem with the current code -- I understand that all the memory it uses (with i_strdup and friends) is allocated from the default pool, which I assume will be freed eventually. If the goal of an dedicated pool is to free the memory early the code using the auth-master API will have to allocate and free this pool, I don't see the advantage here... But then, on a second thought I _do_ see the advantage of a consistent way to do things like this. ;-) >> Btw, on dedicated vs. default resources, I wasn't quite sure if it was a >> good idea to use the default ioloop. Any thoughts on that? > > For deliver it doesn't matter, but for imap you really should create a > new ioloop or things will probably break. Yes, I know (already made this mistake)... ;-) The question is, should the ioloop be an extra argument to auth_master_init? >> > (also p_array_init(&reply->extra_fields) would be cleaner to do inside >> > the lookup code than require it to be done externally). >> >> Hmm, the idea was to only fill the extra_fields array when it was >> initialized, but maybe it isn't worth the trouble... > > See above - it's only a short living lookup and this makes code slightly > cleaner since the allocation is done only in one place. :) Ok, I'll make this change. cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpBlrsyToB5G.pgp Description: PGP signature
Re: [Dovecot] New generic userdb lookup api
Timo Sirainen <[EMAIL PROTECTED]> writes: > On Fri, 2008-10-24 at 16:19 +0200, Sascha Wilde wrote: >> Ok, I used auth-master.* -- the new code is in changeset f5ce17153a3d in >> my kolab-branch at >> http://hg.intevation.org/kolab/dovecot-1.2_kolab-branch/ and I made >> deliver use it in 94b00e377a25. >> >> I had no time for thorough testing, but in my test-setup it seems to >> work like before, so at least I didn't break it completely... ;-) > > A couple of things: > > 1. It disconnects after each lookup. Not good if multiple lookups are > done. Then again it probably shouldn't keep the connection alive forever > since the imap connections can run for ages and most of the necessary > lookups are probably done close to each others. Maybe timeout after 1 > minute of idling? I agree that this is something that should be optimized, but I was under the impression, that the current behavior of deliver was just like that -- maybe I'm mistaken, I haven't double-checked that... > 2. conn->to is for auth request timeout. It should be removed after > io_loop_run() so if 1. is fixed it won't leak timeouts. > (The same conn->to could actually be used for the two timeouts - one > value when looking up, another value when idling.) Ack. Unfortunately I'll have to put a working prototype of the "%%h"-feature together before I'll have time to look into that... > 3. Would be nice to get rid of the getenv()s :) The MAIL_CHROOT handling > could be moved to deliver (use it if reply->chroot == NULL). The debug > could be a parameter to auth_master_init(). You are right, and as I moved/left most of the env stuff in deliver/auth-client anyway it is only consequent to handle those two the same -- I'll make this change. > 4. You're leaking memory. Um, yes. *blush* -- at least I added the free for the connection shortly after my announcement... ;-) > Cleanest fix would be to add pool_t pool parameter to > auth_master_user_lookup() and allocate memory only from it I think a free_auth_user_reply function might be preferable. But I have to admit, that I didn't look deeply enough into the memory pool management in dovecot to really know whats The Right Thing To Do[tm]. Btw, on dedicated vs. default resources, I wasn't quite sure if it was a good idea to use the default ioloop. Any thoughts on that? > (also p_array_init(&reply->extra_fields) would be cleaner to do inside > the lookup code than require it to be done externally). Hmm, the idea was to only fill the extra_fields array when it was initialized, but maybe it isn't worth the trouble... cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpIkkYnThP9L.pgp Description: PGP signature
Re: [Dovecot] New generic userdb lookup api (was: New userdb backend for checkpassword like programs)
Timo Sirainen <[EMAIL PROTECTED]> writes: > Hmm. auth-client.c is about performing authentication as a > client. What you're doing is about doing a userdb lookup and > connecting to dovecot-auth as a master. So different file, but I'm > not really sure about the name. Perhaps auth-master.c and > auth_master_init/deinit() auth_master_user_lookup() function? Ok, I used auth-master.* -- the new code is in changeset f5ce17153a3d in my kolab-branch at http://hg.intevation.org/kolab/dovecot-1.2_kolab-branch/ and I made deliver use it in 94b00e377a25. I had no time for thorough testing, but in my test-setup it seems to work like before, so at least I didn't break it completely... ;-) Now I have to go back and finally implement the %%h feature for shared name spaces. cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgp2KZnfTlYwn.pgp Description: PGP signature
Re: [Dovecot] dovecot 1.2: SEGV in acl plugin when selecting a shared mailbox
Timo Sirainen <[EMAIL PROTECTED]> writes: > On Thu, 2008-10-23 at 13:25 +0200, Sascha Wilde wrote: >> Hi Timo, >> >> there is a bug in the acl plugin (in head, _without_ our acl changes), >> which causes an segfault on selecting a shared folder. >> >> * OK [CAPABILITY ...] Dovecot ready. >> x login [EMAIL PROTECTED] secret >> x OK [CAPABILITY ...] Logged in >> y select "users/[EMAIL PROTECTED]/INBOX/bla" >> - Peer has closed the GNUTLS connection > > Fixed: http://hg.dovecot.org/dovecot-1.2/rev/8553bb4c53ad Confirmed. Many thanks once again... :) cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpk59UvuxfVr.pgp Description: PGP signature
Re: [Dovecot] New userdb backend for checkpassword like programs
Sascha Wilde <[EMAIL PROTECTED]> writes: > Timo Sirainen <[EMAIL PROTECTED]> writes: >> On Thu, 2008-10-23 at 16:18 +0200, Sascha Wilde wrote: > [...] >>> 2.) The exported interface in the respective auth-client.h files is >>> different. The solution would be to figure out what the right >>> interface would be > [...] >> Perhaps something like: > [api sketch] > > Looks good to me. One more detail: as lib-auth/auth-client.c already exists. Would it be a good idea to put the new stuff in the same file? And in case not, any suggestions what a new file could be named? cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgp8LyoUd3L7T.pgp Description: PGP signature
Re: [Dovecot] New userdb backend for checkpassword like programs
Timo Sirainen <[EMAIL PROTECTED]> writes: > On Thu, 2008-10-23 at 18:55 +0200, Sascha Wilde wrote: >> Timo Sirainen <[EMAIL PROTECTED]> writes: >> > On Thu, 2008-10-23 at 13:13 +0200, Sascha Wilde wrote: >> >> Timo Sirainen <[EMAIL PROTECTED]> writes: >> >> > On Oct 21, 2008, at 5:27 PM, Sascha Wilde wrote: >> >> >> Sascha Wilde <[EMAIL PROTECTED]> writes: >> >> >>> [userdb-checkpassword] >> >> [...] >> >> > The code is now in dovecot-1.2 tree. >> >> >> >> Unfortunately there is one tiny, but essential change missing: >> > >> > Oh. I guess I should have bothered to test it. :) I added the code to >> > main.c now instead. I'll try merging changes differently the next time. >> >> Thanks. v2.1alpha4? ;-) > > Nah. checkpassword users are rare. :) But important! I don't know if I'm allowed to tell which customer I'm thinking of, though... ;-) sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpwOQaQL3yGm.pgp Description: PGP signature
Re: [Dovecot] New userdb backend for checkpassword like programs
Timo Sirainen <[EMAIL PROTECTED]> writes: > On Thu, 2008-10-23 at 16:18 +0200, Sascha Wilde wrote: [...] >> 2.) The exported interface in the respective auth-client.h files is >> different. The solution would be to figure out what the right >> interface would be [...] > Perhaps something like: [api sketch] Looks good to me. Especially as it solves the "put everything in the environment" problem in a way I like... :-) > I'm not sure about the struct, but maybe something like that. deliver > would then use the struct to set up environment etc. > >> 3.) The deliver version does more than I need, and most certainly more >> than it should in the generic case: the most obvious example is that >> it sets up RESTRICT_* environment and calls >> restrict_access_by_env(TRUE); which surely is nothing I want to >> do in my code... > > Right. And in general putting all the stuff to environment directly > isn't that good. With v1.3's config rewrite I'm hoping to get rid of all > this environment usage. Ok, so I'll touch it as few as possible and leave it in the deliver specific files. >> finally ask the author of the expire plugin to change his code > > That'd basically be me. :-) cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpV4lUK2t9Qk.pgp Description: PGP signature
Re: [Dovecot] New userdb backend for checkpassword like programs
Timo Sirainen <[EMAIL PROTECTED]> writes: > On Thu, 2008-10-23 at 13:13 +0200, Sascha Wilde wrote: >> Timo Sirainen <[EMAIL PROTECTED]> writes: >> > On Oct 21, 2008, at 5:27 PM, Sascha Wilde wrote: >> >> Sascha Wilde <[EMAIL PROTECTED]> writes: >> >>> [userdb-checkpassword] >> [...] >> > The code is now in dovecot-1.2 tree. >> >> Unfortunately there is one tiny, but essential change missing: > > Oh. I guess I should have bothered to test it. :) I added the code to > main.c now instead. I'll try merging changes differently the next time. Thanks. v2.1alpha4? ;-) sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpT8zD7nf5gn.pgp Description: PGP signature
Re: [Dovecot] New userdb backend for checkpassword like programs
Sascha Wilde <[EMAIL PROTECTED]> writes: > Timo Sirainen <[EMAIL PROTECTED]> writes: >> On Wed, 2008-10-22 at 16:15 +0200, Sascha Wilde wrote: >>> There are more than 250LOC in deliver/auth-client.c and I wonder if >>> there is already a higher level api for auth clients? I would have >>> expected something like this in lib-auth, but the stuff in there seems >>> not to be what I'm looking for. Any hints? >> >> plugins/expire-tool/auth-client.c has copy&pasted that code also.. So it >> would be nice if it was put to lib-auth :) > > Ok, I'll consider doing so... :) Having a first look it turns out to be less straight forward then I hoped it would be. While there are significant amounts of code similar in deliver/auth-client.c and expire/auth-client.c they differ in many aspects: 1.) It seems that some code in deliver/auth-client.c has been revised after it was copied to expire/auth-client.c, this is a small problem as I would expect simply using the newer code to be the right thing[tm]. 2.) The exported interface in the respective auth-client.h files is different. The solution would be to figure out what the right interface would be and change the current code to use it. My problem I'm not sure what the right interface would look like, for my use the one in expire/auth-client.h looks more compelling, what do you think? 3.) The deliver version does more than I need, and most certainly more than it should in the generic case: the most obvious example is that it sets up RESTRICT_* environment and calls restrict_access_by_env(TRUE); which surely is nothing I want to do in my code... My current plan is to take only the code from deliver/auth-client and check which parts I need, factor these out to new file in lib-auth (unfortunately lib-auth/auth-client already exists) and finally ask the author of the expire plugin to change his code so that it uses the new stuff in lib-auth (I doubt that I will have the time to do this on my own). Obviously a god answer on 2. is badly needed... ;-) One final question: All the code saves the gathered user data by setting the environment accordingly (especially HOME, which is the one of interest for my code) -- but in my case I'm requesting the data for foreign user so setting HOME wouldn't be good idea. I see two possible solutions: - Simple and stupid: save HOME, call the client-auth code, read HOME and reset its value to the saved one. - Clean but grows the API: export another function from auth-client, which does not set env-vars but returns the requested data in some struct. Any thoughts on that? cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpwRtB98NPj0.pgp Description: PGP signature
[Dovecot] dovecot 1.2: SEGV in acl plugin when selecting a shared mailbox
Hi Timo, there is a bug in the acl plugin (in head, _without_ our acl changes), which causes an segfault on selecting a shared folder. * OK [CAPABILITY ...] Dovecot ready. x login [EMAIL PROTECTED] secret x OK [CAPABILITY ...] Logged in y select "users/[EMAIL PROTECTED]/INBOX/bla" - Peer has closed the GNUTLS connection The dovecot.log shows a segfault: [...] child 4507 (imap) killed with signal 11 This _only_ happens when the shared mailbox wasn't accessed in the same session by any other means like MYRIGHTS or LSUB (when subscribed). After doing one of those selecting works too... If it helps I can generate a gdb backtrace. cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpMC0jO4vex6.pgp Description: PGP signature
Re: [Dovecot] New userdb backend for checkpassword like programs
Timo Sirainen <[EMAIL PROTECTED]> writes:
> On Oct 21, 2008, at 5:27 PM, Sascha Wilde wrote:
>> Sascha Wilde <[EMAIL PROTECTED]> writes:
>>> [userdb-checkpassword]
[...]
> The code is now in dovecot-1.2 tree.
Unfortunately there is one tiny, but essential change missing:
diff -r afdc27e0b665 src/auth/auth.c
--- a/src/auth/auth.c Wed Oct 22 21:11:47 2008 +0300
+++ b/src/auth/auth.c Thu Oct 23 13:11:25 2008 +0200
@@ -1,6 +1,7 @@
/* Copyright (c) 2005-2008 Dovecot authors, see the included COPYING file */
#include "common.h"
+#include "child-wait.h"
#include "network.h"
#include "buffer.h"
#include "str.h"
@@ -32,6 +33,8 @@
auth->verbose_debug = getenv("VERBOSE_DEBUG") != NULL ||
auth->verbose_debug_passwords;
auth->verbose = getenv("VERBOSE") != NULL || auth->verbose_debug;
+
+ child_wait_init();
passdb_p = &auth->passdbs;
masterdb_p = &auth->masterdbs;
@@ -297,5 +300,6 @@
auth_request_handler_deinit();
passdb_cache_deinit();
+ child_wait_deinit();
pool_unref(&auth->pool);
}
cheers
sascha
--
Sascha Wilde OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/ http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
pgpK4sCPJFE6A.pgp
Description: PGP signature
Re: [Dovecot] New userdb backend for checkpassword like programs
Timo Sirainen <[EMAIL PROTECTED]> writes: > On Wed, 2008-10-22 at 16:15 +0200, Sascha Wilde wrote: >> Timo Sirainen <[EMAIL PROTECTED]> writes: >> > On Oct 21, 2008, at 5:27 PM, Sascha Wilde wrote: >> >> Sascha Wilde <[EMAIL PROTECTED]> writes: >> >>> [userdb-checkpassword] >> >> > The code is now in dovecot-1.2 tree. >> >> Thank you, that's great! The only thing I'm missing is the addition to >> the example.conf I made. (I have to admit it was only a stub, though) > > http://hg.dovecot.org/dovecot-1.2/rev/4497c58eaca8 adds some other > missing changes too. I also decided to change AUTHORIZED=YES to > AUTHORIZED=1 initially. I did also think about yes -> done or yes -> > userdb or something similar, but 1 -> 2 seemed the best. Ack. >> There are more than 250LOC in deliver/auth-client.c and I wonder if >> there is already a higher level api for auth clients? I would have >> expected something like this in lib-auth, but the stuff in there seems >> not to be what I'm looking for. Any hints? > > plugins/expire-tool/auth-client.c has copy&pasted that code also.. So it > would be nice if it was put to lib-auth :) Ok, I'll consider doing so... :) cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpRjIAwWXtSd.pgp Description: PGP signature
Re: [Dovecot] New userdb backend for checkpassword like programs
Timo Sirainen <[EMAIL PROTECTED]> writes: > On Oct 21, 2008, at 5:27 PM, Sascha Wilde wrote: >> Sascha Wilde <[EMAIL PROTECTED]> writes: >>> [userdb-checkpassword] > The code is now in dovecot-1.2 tree. Thank you, that's great! The only thing I'm missing is the addition to the example.conf I made. (I have to admit it was only a stub, though) > I did some minor changes, mostly > related to getting coding style consistent with the rest of Dovecot. > It probably would have been possible to have the passdb and userdb > share more code, but it's good enough now. :) I agree. Unfortunately I had no time to factor out the more tricky parts. (There is still a bunch of features we have to implement till November...) Apropos implementing features: I had a look at the deliver code to figure out how to get userdb data From the auth server (I need this in shared-storage.c to implement %%h). There are more than 250LOC in deliver/auth-client.c and I wonder if there is already a higher level api for auth clients? I would have expected something like this in lib-auth, but the stuff in there seems not to be what I'm looking for. Any hints? cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpeioTxhEHDm.pgp Description: PGP signature
Re: [Dovecot] New userdb backend for checkpassword like programs
Sascha Wilde <[EMAIL PROTECTED]> writes: > Timo Sirainen <[EMAIL PROTECTED]> writes: > [...] >> All of this forces that the checkpassword script developer either >> handles the AUTHORIZED environment correctly or it doesn't work at >> all. And it prevents admin from accidentally using the script wrong. > > Ok, you convinced me that your concept has the advantage of forcing the > checkpassword script author to try to implement all aspects of the > spec. > > I'll implement it this way, as it isn't hard to do anyway. Ok. 8ebf5a64e6eb includes the discussed changes. cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpHKPiuZK7n5.pgp Description: PGP signature
Re: [Dovecot] 1.2: Bug in listing of shared mailboxes with dot in user id
Timo Sirainen <[EMAIL PROTECTED]> writes: > On Fri, 2008-10-17 at 15:18 +0200, Sascha Wilde wrote: > >> now, when I subscribe to a shared mailbox of another user with an dot in >> the users id, like: users/[EMAIL PROTECTED]/INBOX/foo and I list my >> subscribed mailboxes I get: >> >> l001 lsub "" "*" >> * LSUB () "/" "users/[EMAIL PROTECTED]/com/INBOX/foo" >> >> as you can see the dot in the user-id got normalized to the hierarchy >> seperator `/' -- which of cause is wrong. ;-) > > Did several fixes to get this working: > http://hg.dovecot.org/dovecot-1.2/rev/4296aa3fbb75 After re-subscribing the folder with your patch the listing looks right. Thanks! cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpZrv9iESOo8.pgp Description: PGP signature
Re: [Dovecot] New userdb backend for checkpassword like programs
Timo Sirainen <[EMAIL PROTECTED]> writes: [...] > All of this forces that the checkpassword script developer either > handles the AUTHORIZED environment correctly or it doesn't work at > all. And it prevents admin from accidentally using the script wrong. Ok, you convinced me that your concept has the advantage of forcing the checkpassword script author to try to implement all aspects of the spec. I'll implement it this way, as it isn't hard to do anyway. But I have to say, that I'm not really sure about the merits of trying to force other developers to do the right thing like this. The developer can still change the environment only when AUTHORIZED is set (why would he do something like that you ask? Maybe he did just copy and paste from a combined passdb and userdb checkpassword), the admin writing his own broken userdb checkpassword script still can use it for passdb, it only won't work for userdb (he will use prefetch until he finds the bug...). After all, nothing is foolproof to a sufficiently talented fool. ;-) cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpRYyF9HtkJV.pgp Description: PGP signature
Re: [Dovecot] New userdb backend for checkpassword like programs
Timo Sirainen <[EMAIL PROTECTED]> writes: > On Oct 20, 2008, at 8:00 PM, Sascha Wilde wrote: > >> My solution: >> >>1. The userdb-only checkpassword script sees no AUTHORIZED in the >> environment and returns with an exit code != 0[0] > > You assume that the script actually checks this. More than that, I defined that it MUST do so. As you said, it's a new variant, so _we_ can define how it has to behave. > There's no requirement that a userdb-only script needs to bother doing > it. The use of AUTHORIZED environment is necessary only if the script > wants to handle both passdb and userdb. But you are requiring the userdb-only checkpassword program to set AUTHORIZED (or any other environment variable) to a specific value. Why should a developer ignoring my requirement bother to obey yours? cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpXie3HUZoki.pgp Description: PGP signature
Re: [Dovecot] New userdb backend for checkpassword like programs
Timo Sirainen <[EMAIL PROTECTED]> writes: > On Oct 20, 2008, at 7:08 PM, Sascha Wilde wrote: > >> I understand the idea now, but see above: we need the (userdb only) >> checkpassword script to follow our rules anyway, so instead of doing >> magic to the environment and checking for this in checkpassword- >> reply it >> should be sufficient for the script to fail if AUTHORIZED wasn't set. >> >> Or am I missing something? > > The problem is that you said that AUTHORIZED is set automatically when > userdb checkpassword script is called. Yes, the userdb back end sets AUTHORIZED. > So the script doesn't have to set it manually. Yes, the script doesn't change the environment in any other way than any qmail checkpassword script would. > That makes the script automatically work as userdb > script (because AUTHORIZED is set automatically) ...yes, when it is called by the userdb backend... > and as passdb script (because AUTHORIZED isn't set automatically). ...when it is called by the passdb backend, yes. > That kind of breaks the idea. Sorry I don't get it. The case we want to prevent is that a userdb only checkpassword gets accidentally abused by passdb for authorization, right? Your solution is: 1. The userdb-only checkpassword script changes the environment in some way. 2. checkpassword-reply detects the change and returns with an exit code != 0 3. The passdb backend sees its child's exit code is != 0 and so the authorization has failed My solution: 1. The userdb-only checkpassword script sees no AUTHORIZED in the environment and returns with an exit code != 0[0] 2. The passdb backend sees its child's exit code is != 0 and so the authorization has failed So whats the functional difference? cheers sascha [0] and != 2 as this is what the userdb backend expects for success as we decided. -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpIAkN16eNOx.pgp Description: PGP signature
Re: [Dovecot] New userdb backend for checkpassword like programs
Timo Sirainen <[EMAIL PROTECTED]> writes: > On Mon, 2008-10-20 at 17:26 +0200, Sascha Wilde wrote: >> Currently the code handles only two cases: success and (any kind of) >> error. The passdb-checkpassword stuff seems not to handle "user >> doesn't exist" in any special way, so I don't see why the userdb >> backend should. > > The difference is that userdb lookups need to know if the user exists or > if the error is only temporary. That determines if deliver returns > EX_TEMPFAIL or EX_NOUSER. Ah, I see. I'll implement it accordingly. >> > - a valid userdb checkpassword script shouldn't be a valid passdb >> > checkpassword script to avoid accidents. I guess this could be done by >> >> I don't agree here. I think it would be ok to have only one >> checkpassword executable to handle both cases. > > Yes, but a checkpassword script written to handle *only* userdb lookups > shouldn't be a valid passdb script. Ok, we can agree on that. But I think it would be sufficient to say that such an userdb only checkpassword script MUST fail if AUTHORIZED is not set. >> > 1) Require userdb scripts to set USERDB environment. >> > >> > 2) checkpassword-reply checks if USERDB environment is set. If it is, >> > return exit code 2 instead of 0. >> > >> > 3) userdb-checkpassword.c's success exit code is 2. exit code 0 would >> > produce failure. >> > >> > Hmm. Or perhaps instead of USERDB change the AUTHORIZED environment's >> > value to something else. >> >> 1) I fully agree that it is a very good idea that, if AUTHORIZED is set >>checkpassword-reply should return something != 0 at success and >>userdb-checkpassword should expect this very value. >> >>I'll implement that. >> >> 2) I don't understand why the checkpassword program[0] should change the >>environment in any way. > > The idea was that if there's a checkpassword script that handles only > userdb lookups and it's tried to be used as passdb checkpassword, it > would fail because checkpassword-reply sees AUTHORIZED=2 environment, > which would cause it to return 2 which would cause passdb checkpassword > to fail the authentication. I understand the idea now, but see above: we need the (userdb only) checkpassword script to follow our rules anyway, so instead of doing magic to the environment and checking for this in checkpassword-reply it should be sufficient for the script to fail if AUTHORIZED wasn't set. Or am I missing something? cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpYhzqfcC05l.pgp Description: PGP signature
Re: [Dovecot] New userdb backend for checkpassword like programs
Timo Sirainen <[EMAIL PROTECTED]> writes: > On Fri, 2008-10-17 at 19:04 +0200, Sascha Wilde wrote: >> http://hg.intevation.org/kolab/dovecot-1.2_kolab-branch/ >> >> Timo, what would be needed to get the new back end upstream? > > Some small things: > > - rename checkpassword-common.c to db-checkpassword.c so it's > consistent with others. [x] done > - userdb checkpassword is a new dovecot-specific extension, so you can > drop all vpopmail etc. exit code handlers. Just 3 needed: success, user > doesn't exist and internal error (also being the default). [x] done Currently the code handles only two cases: success and (any kind of) error. The passdb-checkpassword stuff seems not to handle "user doesn't exist" in any special way, so I don't see why the userdb backend should. > - a valid userdb checkpassword script shouldn't be a valid passdb > checkpassword script to avoid accidents. I guess this could be done by I don't agree here. I think it would be ok to have only one checkpassword executable to handle both cases. > 1) Require userdb scripts to set USERDB environment. > > 2) checkpassword-reply checks if USERDB environment is set. If it is, > return exit code 2 instead of 0. > > 3) userdb-checkpassword.c's success exit code is 2. exit code 0 would > produce failure. > > Hmm. Or perhaps instead of USERDB change the AUTHORIZED environment's > value to something else. 1) I fully agree that it is a very good idea that, if AUTHORIZED is set checkpassword-reply should return something != 0 at success and userdb-checkpassword should expect this very value. I'll implement that. 2) I don't understand why the checkpassword program[0] should change the environment in any way. cheers sascha [0] I guess that's what you mean by "userdb scripts" -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpOYKSU8z0El.pgp Description: PGP signature
[Dovecot] New userdb backend for checkpassword like programs
As announced in MID <[EMAIL PROTECTED]> I wrote[0] a new userdb back end, which uses a checkpassword like program to retrieve user data. This is needed to get computed user data without authentication for the LDA or the yet to be implemented %%h variable in shared user folder name spaces... The back end needs a special checkpassword program which follows the qmail semantics but additionally provides the user data without password verification when the environment variable AUTHORIZED is set.[1] I have done some code cleanup (mainly factoring out common code of the passdb and userdb back ends) and you can found the current version, alongside with our acl-plugin enhancements, here: http://hg.intevation.org/kolab/dovecot-1.2_kolab-branch/ Timo, what would be needed to get the new back end upstream? cheers sascha [0] Well mostly copy and paste from the existing passdb-checkpassword... [1] The variable name needs some evaluation: it seems, that courier knows an environment variable AUTHENTICATED, which might be a good choice for us, too -- on the other hand it might be totally wrong. ;-) -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpfrdEnqeJJV.pgp Description: PGP signature
[Dovecot] 1.2: Bug in listing of shared mailboxes with dot in user id
In dovecot 1.2 I can create a shared name space like this:
namespace shared {
separator = /
prefix = users/%%u/
location =
Maildir:/PATH/TO/spool/%%u/maildir:INDEX=/PATH/TO/spool/%u/maildir/shared_idx
subscriptions = no
}
now, when I subscribe to a shared mailbox of another user with an dot in
the users id, like: users/[EMAIL PROTECTED]/INBOX/foo and I list my
subscribed mailboxes I get:
l001 lsub "" "*"
* LSUB () "/" "users/[EMAIL PROTECTED]/com/INBOX/foo"
as you can see the dot in the user-id got normalized to the hierarchy
seperator `/' -- which of cause is wrong. ;-)
cheers
sascha
--
Sascha Wilde OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/ http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
pgpeWD3183Xes.pgp
Description: PGP signature
Re: [Dovecot] imap segfaults in dovecot 1.2 on logout
Timo Sirainen <[EMAIL PROTECTED]> writes:
> On Thu, 2008-10-16 at 13:49 +0200, Sascha Wilde wrote:
>> Timo Sirainen <[EMAIL PROTECTED]> writes:
>> > On Oct 15, 2008, at 5:57 PM, Sascha Wilde wrote:
>> >
>> >> #1 0x0806ab6c in command_unregister (name=0x815b9ab "LOGOUT") at
>> >> commands.c:83
>> >> 83 if (strcasecmp(cmd[i].name, name) == 0) {
>> >> (gdb) p cmd[i]
>> >> $1 = {name = 0xb7e65ce7 , func =
>> >> 0xb7e6432d, flags = 0}
>> >> ^^^
>> >>
>> >> For some reasons this does _not_ happen when I simply close the
>> >> connection (without explicitly logging out)...
>> >
>> > Your plugin isn't probably unregistering some command it registered
>> > and the plugin is unloaded before commands_deinit() is called.
>>
>> As said in my other mail, that was indeed the problem and it is now
>> solved. The question still left is: why didn't I see the segfoult in
>> the logs when the connection was closed hard?
>>
>> A quick look with gdb shows, that the deinit stuff is called in both
>> cases, so I'd guess its an logging issue?
>
> I've no idea really. Perhaps it was just luck? :)
No, this was really reproducible, I did it a couple of times, it always
looked like this:
With IMAP "LOGOUT" command:
dovecot[22653]: IMAP([EMAIL PROTECTED]): Disconnected: Logged out
bytes=31/953
dovecot[22653]: child 22687 (imap) killed with signal 11
Connection closed without LOGOUT:
dovecot[22653]: IMAP([EMAIL PROTECTED]): Connection closed bytes=0/272
and no hint of signal 11...
cheers
sascha
--
Sascha Wilde OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/ http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
pgpaWrHcRUE8r.pgp
Description: PGP signature
Re: [Dovecot] imap segfaults in dovecot 1.2 on logout
Timo Sirainen <[EMAIL PROTECTED]> writes:
> On Oct 15, 2008, at 5:57 PM, Sascha Wilde wrote:
>
>> #1 0x0806ab6c in command_unregister (name=0x815b9ab "LOGOUT") at
>> commands.c:83
>> 83 if (strcasecmp(cmd[i].name, name) == 0) {
>> (gdb) p cmd[i]
>> $1 = {name = 0xb7e65ce7 , func =
>> 0xb7e6432d, flags = 0}
>> ^^^
>>
>> For some reasons this does _not_ happen when I simply close the
>> connection (without explicitly logging out)...
>
> Your plugin isn't probably unregistering some command it registered
> and the plugin is unloaded before commands_deinit() is called.
As said in my other mail, that was indeed the problem and it is now
solved. The question still left is: why didn't I see the segfoult in
the logs when the connection was closed hard?
A quick look with gdb shows, that the deinit stuff is called in both
cases, so I'd guess its an logging issue?
cheers
sascha
--
Sascha Wilde OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/ http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
pgpdqo8fRd7BR.pgp
Description: PGP signature
Re: [Dovecot] deliver does not work with new shared namespaces in dovecot 1.2
Timo Sirainen <[EMAIL PROTECTED]> writes: > On Oct 15, 2008, at 5:04 PM, Sascha Wilde wrote: > >> Oct 15 14:37:43 burlywood3 deliver([EMAIL PROTECTED])[24502]: >> Namespace 'users/': shared: Shared namespace prefix contains unknown >> variables > > Fixed: http://hg.dovecot.org/dovecot-1.2/rev/0a8320a714b5 Thanks. I can confirm that it works now. cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgppoeXmfhaqp.pgp Description: PGP signature
Re: [Dovecot] imap segfaults in dovecot 1.2 on logout
Bernhard Herzog <[EMAIL PROTECTED]> writes: > On 15.10.2008, Bernhard Herzog wrote: >> I recall having a similar problem with the Annotation plugin. IIRC it had >> something to do with not unregistering commands properly when the plugin >> was unloaded. In that case the array of known commands retains dangling >> pointers to the names of the commands that point to the unloaded shared >> object file. > > I think this is indeed the case with the ACL plugin if it is patched to > implement the ACL IMAP commands, as is the case in the kolab branch. The > commands are only unregistered if acl_next_hook_mail_storage_created != NULL. > > Now that variale is set in acl_plugin_init but there's no guarantee that it > will always be != NULL afterwards. If the ACL plugin is the first plugin to > change hook_mail_storage_created, acl_next_hook_mail_storage_created will be > NULL after acl_plugin_init has been executed and registered the commands, but > the deinit function will not unregister the commands. Yes, I came to the same conclusion. I checked in a fix to the acl-branch[0] as well as to the generic kolab-branch[1] repository. cheers sascha [0] http://hg.intevation.org/kolab/dovecot-1.2_acl-branch/ [1] http://hg.intevation.org/kolab/dovecot-1.2_kolab-branch/ -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpneae0DB4uJ.pgp Description: PGP signature
[Dovecot] imap segfaults in dovecot 1.2 on logout
Hi Timo,
when logging out like
a001 logout
the imap child dies from signal 11. The back trace looks like this:
Program received signal SIGSEGV, Segmentation fault.
0xb7ed4991 in strcasecmp () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0 0xb7ed4991 in strcasecmp () from /lib/tls/i686/cmov/libc.so.6
#1 0x0806ab6c in command_unregister (name=0x815b9ab "LOGOUT") at commands.c:83
#2 0x0806ac56 in command_unregister_array (cmdarr=0x815ba8c, count=25) at
commands.c:101
#3 0x0806ae36 in commands_deinit () at commands.c:146
#4 0x08073a8f in main_deinit () at main.c:273
#5 0x08073b7b in main (argc=1, argv=0xbfacb884, envp=0xbfacb88c) at main.c:310
(gdb) up
#1 0x0806ab6c in command_unregister (name=0x815b9ab "LOGOUT") at commands.c:83
83 if (strcasecmp(cmd[i].name, name) == 0) {
(gdb) p cmd[i]
$1 = {name = 0xb7e65ce7 , func = 0xb7e6432d,
flags = 0}
^^^
For some reasons this does _not_ happen when I simply close the
connection (without explicitly logging out)...
cheers
sascha
--
Sascha Wilde OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/ http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
pgpJBSIAql0go.pgp
Description: PGP signature
[Dovecot] deliver does not work with new shared namespaces in dovecot 1.2
Hi Timo, checking my new userdb-checkpassword back end is stumbled across the fact, that the new shared namespace definitions possible in dovecot stop deliver from working. The log says: Oct 15 14:37:43 burlywood3 deliver([EMAIL PROTECTED])[24502]: Namespace: type=shared, prefix=users/%%u/, sep=/, inbox=no, hidden=no, list=no, subscriptions=no Oct 15 14:37:43 burlywood3 deliver([EMAIL PROTECTED])[24502]: Namespace 'users/': shared: Shared namespace prefix contains unknown variables Oct 15 14:37:43 burlywood3 deliver([EMAIL PROTECTED])[24502]: Fatal: Namespace initialization failed I guess the primary (only?) case where these shared namespaces are needed for delivery is the use of sieve. cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgp7dKCAEfeqQ.pgp Description: PGP signature
Re: [Dovecot] Patch: use child_wait in passdb-checkpassword
Sascha Wilde <[EMAIL PROTECTED]> writes: > Sascha Wilde <[EMAIL PROTECTED]> writes: >> Now I'll try to do the same for my userdb, so that they should work at >> the same time -- stay tuned... > > I have a first working beta. I'll put a repository with the changes > on line soon... Done. You can find all the stuff here: http://hg.intevation.org/kolab/dovecot-1.2_kolab-branch/ The addition of child_wait and changes to passdb-checkpassword are in changeset 53b57b123f74, the new userdb back end is in a4d3ea1e52bc. Next steps will be cleaning up and documentation (at least in the sample config). cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpYTM1H2c3ZA.pgp Description: PGP signature
Re: [Dovecot] Patch: use child_wait in passdb-checkpassword
Sascha Wilde <[EMAIL PROTECTED]> writes:
> Thanks! Seems indeed helpful. I have changed passdb-checkpassword to
> use the child-wait stuff, see attached patch. (I have put
> child-wait.[ch] into src/lib/)
Doh! Forgot to attach the patch (which isn't to bad as it was faulty
anyway...).
This time I really attached it!
> Now I'll try to do the same for my userdb, so that they should work at
> the same time -- stay tuned...
I have a first working beta. I'll put a repository with the changes
on line soon...
cheers
sascha
--
Sascha Wilde OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/ http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
diff -r cd9fb9098f07 src/auth/auth.c
--- a/src/auth/auth.c Wed Oct 15 12:53:05 2008 +0200
+++ b/src/auth/auth.c Wed Oct 15 13:24:49 2008 +0200
@@ -1,6 +1,7 @@
/* Copyright (c) 2005-2008 Dovecot authors, see the included COPYING file */
#include "common.h"
+#include "child-wait.h"
#include "network.h"
#include "buffer.h"
#include "str.h"
@@ -32,6 +33,8 @@
auth->verbose_debug = getenv("VERBOSE_DEBUG") != NULL ||
auth->verbose_debug_passwords;
auth->verbose = getenv("VERBOSE") != NULL || auth->verbose_debug;
+
+ child_wait_init();
passdb_p = &auth->passdbs;
masterdb_p = &auth->masterdbs;
@@ -297,5 +300,6 @@
auth_request_handler_deinit();
passdb_cache_deinit();
+ child_wait_deinit();
pool_unref(&auth->pool);
}
diff -r cd9fb9098f07 src/auth/passdb-checkpassword.c
--- a/src/auth/passdb-checkpassword.c Wed Oct 15 12:53:05 2008 +0200
+++ b/src/auth/passdb-checkpassword.c Wed Oct 15 13:24:49 2008 +0200
@@ -12,6 +12,7 @@
#include "hash.h"
#include "env-util.h"
#include "safe-memset.h"
+#include "child-wait.h"
#include
#include
@@ -39,6 +40,9 @@
int exit_status;
unsigned int exited:1;
};
+
+struct child_wait *checkpassword_passdb_children;
+
static void checkpassword_request_close(struct chkpw_auth_request *request)
{
@@ -142,58 +146,41 @@
}
}
-static void sigchld_handler(int signo ATTR_UNUSED, void *context)
+static void sigchld_handler(struct child_wait_status *child_wait_status, void *context)
{
+ int status = child_wait_status->status;
+ pid_t pid = child_wait_status->pid;
struct checkpassword_passdb_module *module = context;
- struct chkpw_auth_request *request;
- int status;
- pid_t pid;
+ struct chkpw_auth_request *request =
+ hash_lookup(module->clients, POINTER_CAST(pid));
- /* FIXME: if we ever do some other kind of forking, this needs fixing */
- while ((pid = waitpid(-1, &status, WNOHANG)) != 0) {
- if (pid == -1) {
- if (errno != ECHILD && errno != EINTR)
-i_error("waitpid() failed: %m");
- return;
- }
+ if (request == NULL) {
+ i_error("checkpassword: sighandler called for unknown child %d", pid);
+ return;
+ }
- request = hash_lookup(module->clients, POINTER_CAST(pid));
- if (request == NULL) {
- /* unknown child finished */
- if (WIFSIGNALED(status)) {
-i_error("checkpassword: Unknown child %s died "
- "with signal %d", dec2str(pid),
- WTERMSIG(status));
- }
- continue;
- }
+ if (WIFSIGNALED(status)) {
+ i_error("checkpassword: Child %s died with signal %d",
+ dec2str(pid), WTERMSIG(status));
+ } else if (WIFEXITED(status)) {
+ request->exited = TRUE;
+ request->exit_status = WEXITSTATUS(status);
- if (WIFSIGNALED(status)) {
- i_error("checkpassword: Child %s died with signal %d",
-dec2str(pid), WTERMSIG(status));
- } else if (WIFEXITED(status)) {
- request->exited = TRUE;
- request->exit_status = WEXITSTATUS(status);
+ auth_request_log_debug(request->request,
+ "checkpassword", "exit_status=%d",
+ request->exit_status);
- auth_request_log_debug(request->request,
-"checkpassword", "exit_status=%d",
-request->exit_status);
-
- checkpassword_request_half_finish(request);
- request = NULL;
- } else {
- /* shouldn't happen */
- auth_request_log_debug(request->request,
-"checkpassword", "Child exited with status=%d",
-status);
- }
-
- if (request != NULL) {
- checkpassword_request_finish(request,
-PASSDB_RESULT_INTERNAL_FAILURE);
- }
+ checkpassword_request_half_finish(request);
+ request = NULL;
+ } else {
+ /* shouldn't happen */
+ auth_request_log_debug(request->request,
+ "checkpassword", "Child exited with status=%d",
+ status);
+ checkpassword_request_finish(request, PASSDB_RESULT_INTERNAL_FAI
[Dovecot] Patch: use child_wait in passdb-checkpassword (was: Initial support for shared mailboxes)
Timo Sirainen <[EMAIL PROTECTED]> writes: > On Oct 11, 2008, at 10:52 AM, Sascha Wilde wrote: >> The proposed change is not sufficient, the only reason why my test >> didn't fail was, that I used an other passdb backend, so that my >> userdb >> backend was the only one registering a SIGCHILD handler... > > This might be helpful: > > http://hg.dovecot.org/icecap/file/401c2bc71594/src/lib/child-wait.h > http://hg.dovecot.org/icecap/file/401c2bc71594/src/lib/child-wait.c Thanks! Seems indeed helpful. I have changed passdb-checkpassword to use the child-wait stuff, see attached patch. (I have put child-wait.[ch] into src/lib/) Now I'll try to do the same for my userdb, so that they should work at the same time -- stay tuned... cheer sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpmk0FIGETKn.pgp Description: PGP signature
Re: [Dovecot] Initial support for shared mailboxes
Sascha Wilde <[EMAIL PROTECTED]> writes: > Sascha Wilde <[EMAIL PROTECTED]> writes: >> Timo Sirainen <[EMAIL PROTECTED]> writes: >>> On Sep 30, 2008, at 6:08 PM, Sascha Wilde wrote: >> [...] >>>> So I guess what is needed is a new userdb backend which is explicitly >>>> runs an arbitrary external program to get the user data (instead of >>>> caching the passdb results). >>> >>> Right. Perhaps the passdb checkpassword code could be used as userdb >>> too, just with an added extra variable specifying if it's a passdb or >>> a userdb lookup. >> >> I just started to work on this feature > > I have made a first rough sketch of the userdb-checkpassword back end, > basically by copying the code of the passdb version. Now I stumbled > upon the note "FIXME: if we ever do some other kind of forking, this > needs fixing" in sigchld_handler(). > > The only problem I experienced is, that the handler dosen't return, when > the signaling child wasn't listed in the modules clients -- but simply > replacing the continue with return like this: Please ignore this statement -- wrong test, wrong result ... The proposed change is not sufficient, the only reason why my test didn't fail was, that I used an other passdb backend, so that my userdb backend was the only one registering a SIGCHILD handler... cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpdDygB0XVTs.pgp Description: PGP signature
Re: [Dovecot] Initial support for shared mailboxes
Sascha Wilde <[EMAIL PROTECTED]> writes:
> Timo Sirainen <[EMAIL PROTECTED]> writes:
>> On Sep 30, 2008, at 6:08 PM, Sascha Wilde wrote:
> [...]
>>> So I guess what is needed is a new userdb backend which is explicitly
>>> runs an arbitrary external program to get the user data (instead of
>>> caching the passdb results).
>>
>> Right. Perhaps the passdb checkpassword code could be used as userdb
>> too, just with an added extra variable specifying if it's a passdb or
>> a userdb lookup.
>
> I just started to work on this feature
I have made a first rough sketch of the userdb-checkpassword back end,
basically by copying the code of the passdb version. Now I stumbled
upon the note "FIXME: if we ever do some other kind of forking, this
needs fixing" in sigchld_handler().
The only problem I experienced is, that the handler dosen't return, when
the signaling child wasn't listed in the modules clients -- but simply
replacing the continue with return like this:
--- a/src/auth/passdb-checkpassword.c Fri Oct 10 12:06:06 2008 +0200
+++ b/src/auth/passdb-checkpassword.c Fri Oct 10 21:34:36 2008 +0200
@@ -165,7 +165,7 @@
"with signal %d", dec2str(pid),
WTERMSIG(status));
}
- continue;
+ return;
}
if (WIFSIGNALED(status)) {
seems to fix this. The next handler is called and every thing seems to
work well (at least at a first very short test).
Is there any reason not to do so? And are there any other issues you
had in mind writing the FIXME?
cheers
sascha
--
Sascha Wilde OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/ http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
pgpjBtt4OXRgC.pgp
Description: PGP signature
Re: [Dovecot] shared mailboxes in 1.2 question
Timo Sirainen <[EMAIL PROTECTED]> writes: > On Thu, 2008-10-09 at 13:11 +0300, Timo Sirainen wrote: >> So it's still missing the "users who have mailboxes shared to you" >> discovery missing. > > http://dovecot.org/list/dovecot/2006-October/017082.html lists some > options for how to implement that. > > I guess the dictionary way would work, although if it gets desynced with > the ACL files (or completely corrupted), it may be difficult to get it > back to sync unless it's able to rebuild the database. Thanks for all the useful input, we'll get back to it as soon as we start to work on this. cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpfGE1QpjQ3A.pgp Description: PGP signature
Re: [Dovecot] shared mailboxes in 1.2 question
Timo Sirainen <[EMAIL PROTECTED]> writes: > On Thu, 2008-10-09 at 10:03 +0200, Sascha Wilde wrote: >> It seems to work now for subscribing and selecting (and therefor for >> lsub and fetch) -- but LIST still bails out: >> >> l2 list "" "*" >> * LIST (\HasChildren) "/" "INBOX" >> * LIST (\HasNoChildren) "/" "INBOX/Calendar" >> * LIST (\HasNoChildren) "/" "INBOX/Contacts" >> * LIST (\HasNoChildren) "/" "INBOX/Journal" >> * LIST (\HasNoChildren) "/" "INBOX/Notes" >> * LIST (\HasNoChildren) "/" "INBOX/Tasks" >> * LIST (\HasNoChildren) "/" "INBOX/bla" >> l2 NO Unknown internal list error >> >> This happens as soon as dovecot stumbles upon the shared namespace, so >> that other public name spaces, which otherwise work, are affected, too. > > Right, that's intentional. You could set list=no to that namespace Ah, that makes sence, thanks for the hint. > to avoid the error, or implement the listing code. :) Thats what we will do... ;-) cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpfIv7VRtA6A.pgp Description: PGP signature
Re: [Dovecot] shared mailboxes in 1.2 question
Timo Sirainen <[EMAIL PROTECTED]> writes: > On Wed, 2008-10-08 at 17:39 +0200, Sascha Wilde wrote: >> Timo Sirainen <[EMAIL PROTECTED]> writes: >> >> > On Oct 8, 2008, at 5:33 PM, Sascha Wilde wrote: >> > >> >> s002 subscribe "users/[EMAIL PROTECTED]/blablabla" >> >> s002 NO [TRYCREATE] Mailbox doesn't exist: users/[EMAIL PROTECTED]/ >> >> blablabla >> > >> > I think this should have worked, I'll look into it. >> >> IMO the other one: >> s001 subscribe "users/[EMAIL PROTECTED]/INBOX/blablabla" >> should have worked. >> >> Or is the default namespace prefix "INBOX/" instead of empty? >> Furthermore, please notice the different error: when the mailbox exists >> dovecot claims "Invalid mailbox name" otherwise it says "[TRYCREATE] >> Mailbox doesn't exist" which is indeed true. > > Fixed: http://hg.dovecot.org/dovecot-1.2/rev/c465b10a76fd And thanks again for being so responsive and making this stunningly fast fixes! ;) It seems to work now for subscribing and selecting (and therefor for lsub and fetch) -- but LIST still bails out: l2 list "" "*" * LIST (\HasChildren) "/" "INBOX" * LIST (\HasNoChildren) "/" "INBOX/Calendar" * LIST (\HasNoChildren) "/" "INBOX/Contacts" * LIST (\HasNoChildren) "/" "INBOX/Journal" * LIST (\HasNoChildren) "/" "INBOX/Notes" * LIST (\HasNoChildren) "/" "INBOX/Tasks" * LIST (\HasNoChildren) "/" "INBOX/bla" l2 NO Unknown internal list error This happens as soon as dovecot stumbles upon the shared namespace, so that other public name spaces, which otherwise work, are affected, too. cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpuHAmke8lPG.pgp Description: PGP signature
Re: [Dovecot] Initial support for shared mailboxes
Timo Sirainen <[EMAIL PROTECTED]> writes: > On Wed, 2008-10-08 at 12:54 +0200, Sascha Wilde wrote: >> I just started to work on this feature and for testing purpose I wrote a >> very simple dummy checkpassword program. But I have a problem setting >> the UID and GID: >> >> I'm using: >> >> userdb_uid=12345 >> userdb_gid=12345 >> EXTRA="userdb_uid userdb_gid" >> export userdb_uid userdb_gid EXTRA >> >> according to http://wiki.dovecot.org/PasswordDatabase/CheckPassword but > > I guess it worked more or less accidentally at some point. Changed now > so it should really work: > http://hg.dovecot.org/dovecot-1.2/rev/a38778911fa9 Thanks, works now for me as expected. cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgploq3KrSOdc.pgp Description: PGP signature
Re: [Dovecot] shared mailboxes in 1.2 question
Robert Schetterer <[EMAIL PROTECTED]> writes: > Sascha Wilde schrieb: >> Yes, look at http://hg.intevation.de/kolab/dovecot-1.2_acl-branch as >> announced... ;-) > Hi Sascha, > why you need an extra branch for that ? This is our working repository. The ACL extensions by Matvey aren't ready for upstream but we wanted to give everyone interested access to them. > why not just code into dovecot directly or is it ment as temp split > and later merge ? Yes, its not really a split, its just our development branch and of cause it is intended to get our work upstream so that the repository will become obsolete eventually. cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpmI2ADRd0cS.pgp Description: PGP signature
Re: [Dovecot] shared mailboxes in 1.2 question
Timo Sirainen <[EMAIL PROTECTED]> writes:
> On Oct 8, 2008, at 5:33 PM, Sascha Wilde wrote:
>
>> s002 subscribe "users/[EMAIL PROTECTED]/blablabla"
>> s002 NO [TRYCREATE] Mailbox doesn't exist: users/[EMAIL PROTECTED]/
>> blablabla
>
> I think this should have worked, I'll look into it.
IMO the other one:
s001 subscribe "users/[EMAIL PROTECTED]/INBOX/blablabla"
should have worked.
Or is the default namespace prefix "INBOX/" instead of empty?
Furthermore, please notice the different error: when the mailbox exists
dovecot claims "Invalid mailbox name" otherwise it says "[TRYCREATE]
Mailbox doesn't exist" which is indeed true.
>> s102 select users/[EMAIL PROTECTED]/INBOX/blablabla
>> * OK [CLOSED]
>> s102 NO Invalid mailbox name
>
> Assuming INBOX/ is the namespace prefix,
see above, I assume the namespace prefix is empty.
From the configuration:
namespace private {
separator = /
# Prefix required to access this namespace. This needs to be different for
# all namespaces. For example "Public/".
#prefix =
inbox = yes
}
so prefix is not set, which means, it is set to the default. (Which I
believe to be empty, the comments suggest that, too).
cheers
sascha
--
Sascha Wilde OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/ http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
pgpt9TMxiCH7X.pgp
Description: PGP signature
Re: [Dovecot] shared mailboxes in 1.2 question
Timo Sirainen <[EMAIL PROTECTED]> writes:
> On Oct 6, 2008, at 7:24 PM, Robert Schetterer wrote:
>> users after imap search, otherwise you always need some admin (
>> perhaps
>> with shell permissions ) for editing subcriptions and acls which not
>
> Actually the SUBSCRIBE IMAP command is enough to make the mailboxes
> visible, no admin/shell access needed.
This doesn't work for me.
Actually the whole new shared namespaces feature doesn't work as
expected for me. Using this namespace configuration:
namespace shared {
separator = /
# %%u gets expanded to the remote user. Instead of %%u you can
# also use %%n and %%d.
prefix = users/%%u/
location =
Maildir:/kolab/var/dovecot/spool/%%u/maildir:INDEX=/kolab/var/dovecot/spool/%u/maildir/shared_idx
#location = Maildir:/kolab/var/dovecot/spool/%%u/maildir
subscriptions = no
}
I get errors when using list:
l002 list "" "*"
* LIST (\HasChildren) "/" "INBOX"
* LIST (\HasNoChildren) "/" "INBOX/Calendar"
* LIST (\HasNoChildren) "/" "INBOX/Contacts"
* LIST (\HasNoChildren) "/" "INBOX/Journal"
* LIST (\HasNoChildren) "/" "INBOX/Notes"
* LIST (\HasNoChildren) "/" "INBOX/Tasks"
* LIST (\HasNoChildren) "/" "INBOX/bla"
l002 NO Unknown internal list error
And cant subscribe or select an existing mailbox of another user:
s001 subscribe "users/[EMAIL PROTECTED]/INBOX/blablabla"
s001 NO Invalid mailbox name: users/[EMAIL PROTECTED]/INBOX/blablabla
FWIW referencing an non existent mailbox causes an different error:
s002 subscribe "users/[EMAIL PROTECTED]/blablabla"
s002 NO [TRYCREATE] Mailbox doesn't exist: users/[EMAIL PROTECTED]/blablabla
s102 select users/[EMAIL PROTECTED]/INBOX/blablabla
* OK [CLOSED]
s102 NO Invalid mailbox name
> And IMAP ACL commands are (at least partially) already implemented by
> Kolab people.
Yes, look at http://hg.intevation.de/kolab/dovecot-1.2_acl-branch as
announced... ;-)
cheers
sascha
--
Sascha Wilde OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/ http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
pgp5uXO78u9OK.pgp
Description: PGP signature
Re: [Dovecot] Initial support for shared mailboxes
Timo Sirainen <[EMAIL PROTECTED]> writes: > On Sep 30, 2008, at 6:08 PM, Sascha Wilde wrote: [...] >> So I guess what is needed is a new userdb backend which is explicitly >> runs an arbitrary external program to get the user data (instead of >> caching the passdb results). > > Right. Perhaps the passdb checkpassword code could be used as userdb > too, just with an added extra variable specifying if it's a passdb or > a userdb lookup. I just started to work on this feature and for testing purpose I wrote a very simple dummy checkpassword program. But I have a problem setting the UID and GID: I'm using: userdb_uid=12345 userdb_gid=12345 EXTRA="userdb_uid userdb_gid" export userdb_uid userdb_gid EXTRA according to http://wiki.dovecot.org/PasswordDatabase/CheckPassword but then I get an internal login failure. From the dovecot log: Oct 08 12:42:02 burlywood3 dovecot[3804]: auth(default): prefetch([EMAIL PROTECTED],192.168.11.254): success Oct 08 12:42:02 burlywood3 dovecot[3804]: auth(default): master out: USER[EMAIL PROTECTED] home=/kolab/var/dovecot/spool/[EMAIL PROTECTED]/home uid=0 gid=0 uid=19415 gid=19415 Oct 08 12:42:02 burlywood3 dovecot[3804]: uid specified multiple times for [EMAIL PROTECTED] So am I missing something or is this dovecot extension currently broken? cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpVpA0AkZ0jp.pgp Description: PGP signature
Re: [Dovecot] Dovecot 1.1.x or 1.2, which way to go for Kolab Server?
Timo Sirainen <[EMAIL PROTECTED]> writes: > On Tue, 2008-10-07 at 14:25 +0200, Sascha Wilde wrote: >> There was the dict-server startup problem, which we reported and which >> should be fixed now (I still need to test your fix). >> >> Then there are some (undocumented?) changes in the dict api (and the >> changed dict backend configuration). [...] > OK. I think most of the issues you'll find in 1.2 are things like these. > Either something works or it doesn't (mainly because I'm so lazy at > testing changes myself), but there shouldn't be any stability-related > problems. And these "doesn't work" bugs can be fixed quickly when > they're reported. This sounds very promising and fits with our decision to recommend our customer to build upon 1.2. cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpHKx9H0sZNT.pgp Description: PGP signature
Re: [Dovecot] Dovecot 1.1.x or 1.2, which way to go for Kolab Server?
Hi Timo, thanks for the reply, Timo Sirainen <[EMAIL PROTECTED]> writes: > On Tue, 2008-10-07 at 13:08 +0200, Sascha Wilde wrote: >> was written the other day we started to use Dovecot 1.2 for our Kolab >> with Dovecot project, but it turned out that there are quite a bunch of >> issues with 1.2 (which is ok, as it hasn't even been announced as beta >> till now). > > I'd like to hear these issues, since I'm not aware of any v1.2-specific > bugs. There was the dict-server startup problem, which we reported and which should be fixed now (I still need to test your fix). Then there are some (undocumented?) changes in the dict api (and the changed dict backend configuration). And then there are some more dict relates problems/changes causing the metadata/annotations plugin to fail in certain situations -- Bernhard Herzog will report/discuss them in detail soon, in case we decide to use 1.2. So the stuff we stumbled upon was all dict related till now, but on the other hand we haven't done much with 1.2 besides trying to get our changes to work with it... >> How far from being production ready is 1.2 in your view? > > Depends on how fast people report bugs to me.. I've been using it for my > mails without problems for weeks. And about 3 other people also reported > in the last few days that they're running it for their small mail > servers. This sounds promising. >> How hard would it be to get the shared folder/namespace stuff in 1.1.x? >> (or for that matter: who much harder than to do it in 1.2?) > > It requires some mail-storage API changes. I'm not sure if those would > be easy to backport to v1.1. Ok, I'll report the results of our own evaluation, soon. cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpVE4b7b8iSQ.pgp Description: PGP signature
[Dovecot] Dovecot 1.1.x or 1.2, which way to go for Kolab Server?
Hi Timo, Hi *, was written the other day we started to use Dovecot 1.2 for our Kolab with Dovecot project, but it turned out that there are quite a bunch of issues with 1.2 (which is ok, as it hasn't even been announced as beta till now). We have a customer who should get a first test installation of Kolab with Dovecot in the first week of September and for that we need the features mentioned in my other mails, especially the enhanced name spaces for shared folders. (%%h, listing of shared folders, an checkpassword like backend for userdb). So the big decision to make is: - stay with 1.1.x and port the needed shared namespace stuff back from 1.2 or - build on 1.2 and resolve all issues caused by it Timo, do you have any opinion/advice on this? How far from being production ready is 1.2 in your view? How hard would it be to get the shared folder/namespace stuff in 1.1.x? (or for that matter: who much harder than to do it in 1.2?) We are currently evaluating these questions, but I would highly appreciate your comments on this. cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgptpp8Ir37ut.pgp Description: PGP signature
Re: [Dovecot] Annotation plugin for dovecot
Bernhard Herzog <[EMAIL PROTECTED]> writes: > > The plugin is available as a mercurial repository at > http://hg.intevation.org/kolab/dovecot-metadata-plugin/ We just updated the repository to work with dovecot 1.2 -- which in turn breaks it for 1.1.x. If you want to use it with dovecot 1.1.x use the version tagged as "works-with-dovecot-1.1". sascha -- Sascha Wilde OpenPGP key: 4BB86568 Intevation GmbH, Osnabrück http://www.intevation.de/~wilde/ Amtsgericht Osnabrück, HR B 18998 http://www.intevation.de/ Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgp8OeCrQnRVP.pgp Description: PGP signature
[Dovecot] Bug in dovecot 1.2 dict
Hi Timo,
Hi *,
in 1.2 the dict server (tested with sqlite backend) is somewhat broken.
It bails out regularly with "Fatal: dict: Socket already exists: ..."
(looks like a race condition as it doesn't fail always).
We discovered that this new code in dict-server.c seems to be the problem:
server->fd = net_listen_unix_unlink_stale(path, 64);
if (server->fd == -1) {
if (errno == EADDRINUSE)
i_fatal("Socket already exists: %s", path);
else
i_fatal("net_listen_unix(%s) failed: %m", path);
}
replacing it with the old code:
int i = 0;
[...]
while (server->fd == -1) {
server->fd = net_listen_unix(path, 64);
if (server->fd != -1)
break;
if (errno != EADDRINUSE || ++i == 2)
i_fatal("net_listen_unix(%s) failed: %m", path);
/* see if it really exists */
if (net_connect_unix(path) != -1 || errno != ECONNREFUSED)
i_fatal("Socket already exists: %s", path);
/* delete and try again */
if (unlink(path) < 0)
i_fatal("unlink(%s) failed: %m", path);
}
"fixes" the problem. But I think the real fix would have to be done in
the new function `net_listen_unix_unlink_stale'.
cheers
sascha
--
Sascha Wilde OpenPGP key: 4BB86568
Intevation GmbH, Osnabrück http://www.intevation.de/~wilde/
Amtsgericht Osnabrück, HR B 18998 http://www.intevation.de/
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
pgpAC1O2gXijB.pgp
Description: PGP signature
Re: [Dovecot] ACL plugin
Timo Sirainen <[EMAIL PROTECTED]> writes: > On Oct 1, 2008, at 12:57 PM, Sascha Wilde wrote: >> "Matvey Soloviev" <[EMAIL PROTECTED]> writes: >> Matvey finished a first version of the IMAP front end to the ACL >> plugin. >> >> You can find the changes for dovecot 1.1.3 here: >> http://hg.intevation.org/kolab/dovecot-1.1_acl-branch/ >> and as we decided to move on to 1.2, here: >> http://hg.intevation.org/kolab/dovecot-1.2_acl-branch/ [...] > A did a quick look, a few comments: Thanks for your comments. I forwarded them to Matvey, asking him to include them in his changes. cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 Intevation GmbH, Osnabrück http://www.intevation.de/~wilde/ Amtsgericht Osnabrück, HR B 18998 http://www.intevation.de/ Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpCuJJM05HBR.pgp Description: PGP signature
Re: [Dovecot] ACL plugin
"Matvey Soloviev" <[EMAIL PROTECTED]> writes: > I am working on implementing support for the RFC4314 ACL management commands > and responses in the ACL plugin included with dovecot [...] Matvey finished a first version of the IMAP front end to the ACL plugin. You can find the changes for dovecot 1.1.3 here: http://hg.intevation.org/kolab/dovecot-1.1_acl-branch/ and as we decided to move on to 1.2, here: http://hg.intevation.org/kolab/dovecot-1.2_acl-branch/ As of writing this the changes for 1.1.3 and 1.2 are the same (but the 1.2 version isn't really tested yet). cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 Intevation GmbH, Osnabrück http://www.intevation.de/~wilde/ Amtsgericht Osnabrück, HR B 18998 http://www.intevation.de/ Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpdISK83nTZi.pgp Description: PGP signature
Re: [Dovecot] Initial support for shared mailboxes
Timo Sirainen <[EMAIL PROTECTED]> writes: > On Sep 30, 2008, at 6:08 PM, Sascha Wilde wrote: > >>>> Is there a %%h, too? So that, if we have >>>> >>>> mail_location = maildir:~ >>> .. >>>> Another (more specific) problem in this context: Is is it possible >>>> to >>>> determine a users home calling an external program like >>>> checkpassword? >>>> This would be needed in an setup, where the users $HOME is set by an >>>> checkpassword program to an compute value, to access another users >>>> mailbox. >>> >>> This would require doing a userdb lookup from dovecot-auth the same >>> way >>> as deliver or expire-tool does it. >> >> I'm not quite sure what you mean by "this" here, are you referring to >> the proposed `%%h' variable, too or only to my more specific problem >> with computer HOME paths? > > I think it's the same thing. Is it? I might be wrong, but i thought for configurations where userdb doesn't depend on the passdb implementing %%h as the home directory of user %%u should be straight forward. Or am I missing something? [...] >> So I guess what is needed is a new userdb backend which is explicitly >> runs an arbitrary external program to get the user data (instead of >> caching the passdb results). > > Right. Perhaps the passdb checkpassword code could be used as userdb > too, God, so we will try to go this way. > just with an added extra variable specifying if it's a passdb or > a userdb lookup. Or maybe instead of sending "user \0 pass \0" it'd > just send "user". I'm not really sure. In any case I think the reply > should be handled somewhat differently so that the checkpassword can't > accidentally think it's doing a userdb lookup while it's really doing > a passdb lookup and return success. Ack. I or someone else from the Kolab/Dovecot team will write a short proposal on the list as soon as we have one... ;-) cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 Intevation GmbH, Osnabrück http://www.intevation.de/~wilde/ Amtsgericht Osnabrück, HR B 18998 http://www.intevation.de/ Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpsPFjZuUJPr.pgp Description: PGP signature
Re: [Dovecot] Initial support for shared mailboxes
Timo Sirainen <[EMAIL PROTECTED]> writes:
> On Tue, 2008-09-30 at 10:46 +0200, Sascha Wilde wrote:
>> > namespace shared {
>> > separator = /
>> > # %%u gets expanded to the remote user. Instead of %%u you can
>> > # also use %%n and %%d.
>> > prefix = shared/%%u/
>> > location = Maildir:/home/%%u/Maildir:INDEX=~/Maildir/shared/%%u
>> > }
>>
>> Sounds great, and it's an essential feature we need to make Dovecot work
>> with Kolab Server.
>>
>> Is there a %%h, too? So that, if we have
>>
>> mail_location = maildir:~
> ..
>> Another (more specific) problem in this context: Is is it possible to
>> determine a users home calling an external program like checkpassword?
>> This would be needed in an setup, where the users $HOME is set by an
>> checkpassword program to an compute value, to access another users
>> mailbox.
>
> This would require doing a userdb lookup from dovecot-auth the same way
> as deliver or expire-tool does it.
I'm not quite sure what you mean by "this" here, are you referring to
the proposed `%%h' variable, too or only to my more specific problem
with computer HOME paths?
> So sure it'd be possible, but I'm not
> really interested in implementing it yet. I think expire-tool is
> currently using copy&pasted code from deliver, those could be merged
> into some library function and then the namespace code could easily use
> the same function.
But is deliver currently able to utilize an external program to
get user data?
From reading the docs I got the impression that userdb only allows to
use data supplied by an arbitrary program by the "Prefetch" backend in
combination with an checkpassword passdb, and that deliver can't use
this mechanism as the user doesn't login when deliver is run.
So I guess what is needed is a new userdb backend which is explicitly
runs an arbitrary external program to get the user data (instead of
caching the passdb results).
What do you think?
cheers
sascha
--
Sascha Wilde OpenPGP key: 4BB86568
Intevation GmbH, Osnabrück http://www.intevation.de/~wilde/
Amtsgericht Osnabrück, HR B 18998 http://www.intevation.de/
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
pgpGQiBRx4f3e.pgp
Description: PGP signature
Re: [Dovecot] Initial support for shared mailboxes
Timo Sirainen <[EMAIL PROTECTED]> writes:
> Well, I actually started it today since it's needed for replication:
> http://hg.dovecot.org/dovecot-1.2/rev/6dd0c6755afe
>
> Mailboxes can't be listed yet (and I'm not planning on implementing that
> anytime soon), but if you add the wanted mailboxes to subscriptions they
> should be usable by clients. Configuration goes like:
>
> namespace shared {
> separator = /
> # %%u gets expanded to the remote user. Instead of %%u you can
> # also use %%n and %%d.
> prefix = shared/%%u/
> location = Maildir:/home/%%u/Maildir:INDEX=~/Maildir/shared/%%u
> }
Sounds great, and it's an essential feature we need to make Dovecot work
with Kolab Server.
Is there a %%h, too? So that, if we have
mail_location = maildir:~
we can say:
namespace shared {
separator = /
prefix = users/%%u/
location = Maildir:%%h:INDEX=~/Maildir/shared/%%u
}
To make user-mailboxess accessible for other users?
If not, how hard would it be to implement?
Another (more specific) problem in this context: Is is it possible to
determine a users home calling an external program like checkpassword?
This would be needed in an setup, where the users $HOME is set by an
checkpassword program to an compute value, to access another users
mailbox.
cheers
sascha
--
Sascha Wilde OpenPGP key: 4BB86568
Intevation GmbH, Osnabrück http://www.intevation.de/~wilde/
Amtsgericht Osnabrück, HR B 18998 http://www.intevation.de/
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
pgp0uBfCeeg1U.pgp
Description: PGP signature
