[Dovecot] ACL plugin: Is CVE-2008-4578 going to be fixed in 1.0 branch?
Hi! I would like to know if there is a plan to fix CVE-2008-4578 bug (ACL vs. "parent/child/child" mailboxes) in 1.0 branch? I've tried to backport patch from 1.1.4 but with no success. Thanks Michal
[Dovecot] Solving CVE-2008-4870
Hi, we're trying to solve CVE-2008-4870 = rhbz#436287 = dovecot.conf is world readable - possible password exposure. This problem seems to be little more complicated than we thought. dovecot.conf can contain passphrase for ssl key, which is available for everyone since dovecot.conf has world readable permissions. (In CVE's description is note that it RHEL's/Fedora's problem, but it affects all systems imo) We was thinking about few ways how to fix it: 1) 0640 permissions for dovecot.conf - but it can became not readable for dovecot 2) 0640 root:mail and set deliver to group mail with sgid - possible security problem 3) don't store passphrase in dovecot.conf, just ask for it when dovecot's started - can hang boot process, not good As part of investigating, I've found dovecot is storing all variables in environment variables - it means even passphrase? I'm not completely sure, but all variables can be read via /proc//environ (I don't know if it becomes readable in some circumstances.) Is there any plan to solve this problem? Cheers, Michal
Re: [Dovecot] mbox "Next message unexpectedly lost" bug fixed
Timo Sirainen wrote: Good news, everyone! The most annoying bug in v1.1 series should finally be fixed by these patches: http://hg.dovecot.org/dovecot-1.1/rev/f28348c5201e http://hg.dovecot.org/dovecot-1.1/rev/74c47fcfb420 http://hg.dovecot.org/dovecot-1.1/rev/a28520d26b5a http://hg.dovecot.org/dovecot-1.1/rev/539f8d983285 http://hg.dovecot.org/dovecot-1.1/rev/9b7af230f9f0 They also make sure that mbox is never read while it's not locked. I think that could have happened in some situations with v1.1. Hopefully mbox handling will now finally be as stable in v1.1 as it was in v1.0. I'll make a new v1.1 release after seeing what bug fixes are coming from Apple, so probably next week. Hi, could I ask when is planned to release new dovecot 1.1 version? In Fedora there are users affected by this issue, so I'd like to know if I should release new dovecot rpm with this patch or wait for new dovecot version. Cheers, Michal
Re: [Dovecot] v1.1.10 released
Timo Sirainen wrote: On Tue, 2009-01-27 at 14:20 -0600, Eric Rostetter wrote: Quoting Timo Sirainen : I've already written some unit tests in src/tests/. I don't really care if you continue them the way I started or use some other toolset. And What branch(es) should I write them for (1.0, 1.1, and/or 1.2). If multiple branches, which is most important? v1.2, since that's where all the new code goes. I guess they could be backported to v1.1 also but I don't see it as important. I'm hoping for a soonish v1.2.0 release and after that v1.1 won't have as much changes anymore. is there any ETA for dovecot 1.2 beta, rc, final?
Re: [Dovecot] 2.1 upgrade docs?
On 02/17/2012 06:17 PM, e-frog wrote:
On 17.02.2012 18:09, wrote Marc Perkel:
Just wondering if there's any upgrade docs for 2.1 online?
http://wiki2.dovecot.org/Upgrading/2.1
I know about one Fedora user who had to also change:
namespace {
inbox=yes
...
}
to namespace inbox {
and also in sieve (for pigeonhole):
change
include :personal "00-script1.sieve";
to
include :personal "00-script1";
(I did not test dovecot 2.1, I still have 2.0.x on my server)
[Dovecot] dovecot and systemd
Hi all, dovecot supports systemd socket activation. Together with standard unit activation (like old sysv init script), there are two ways how to configure dovecot(only interface:port, not whole configuration). This can result in situation where those configurations does not say the same. Question is what should happen then? For example, lets have dovecot configured to listen for imap(s) and lets have systemd dovecot socket configured to listen for all protocols - pop3(s) and imap(s). When dovecot is configured to start on boot, systemd will start it and dovecot will listen on imap(s) ports. But when dovecot.socket is enabled, it'll listen on pop3(s) too and when new pop3 connection comes, it'll pass it to dovecot and dovecot will serve it. The question is: Should this happen? What exactly should happen when dovecot.conf does not match dovecot.socket configuration? Michal
Re: [Dovecot] dovecot and systemd
On 03/15/2012 03:05 PM, Timo Sirainen wrote: On Thu, 2012-03-15 at 14:34 +0100, Michal Hlavinka wrote: What exactly should happen when dovecot.conf does not match dovecot.socket configuration? Dovecot's systemd code was written by one of you Redhat guys. I had some similar thoughts when I applied the patch, but didn't really know what to do about it, so I didn't do anything. So: I don't know. Maybe some other project has solved this somehow already? Dovecot anyway needs its own internal UNIX listeners. Should all internal inet listeners be disabled? Could Dovecot somehow talk to systemd and ask what listeners it's using for Dovecot and log warnings if they don't match? I don't know that match about systemd. I'll forward this to systemd mailing list and I will let you know once I know more.
Re: [Dovecot] dovecot and systemd
On 03/15/2012 03:05 PM, Timo Sirainen wrote:
On Thu, 2012-03-15 at 14:34 +0100, Michal Hlavinka wrote:
What exactly should happen when
dovecot.conf does not match dovecot.socket configuration?
Dovecot's systemd code was written by one of you Redhat guys. I had some
similar thoughts when I applied the patch, but didn't really know what
to do about it, so I didn't do anything. So: I don't know. Maybe some
other project has solved this somehow already?
Seems other projects did not solve this yet. Most projects provide just
one service. In that case, they serve any connection they get, because
they know what to do.
I've discussed this with systemd upstream and we've decided that the
best solution is to log error message and close that socket.
Dovecot anyway needs its own internal UNIX listeners. Should all
internal inet listeners be disabled? Could Dovecot somehow talk to
systemd and ask what listeners it's using for Dovecot and log warnings
if they don't match?
I don't understand this question completely. What it does already is
that during start up, when dovecot creates sockets, it checks what
sockets already exist and creates only the missing ones.
Systemd provides following functions:
sd_is_fifo (3) - Check the type of a file descriptor
sd_is_mq (3) - Check the type of a file descriptor
sd_is_socket (3) - Check the type of a file descriptor
sd_is_socket_inet (3) - Check the type of a file descriptor
sd_is_socket_unix (3) - Check the type of a file descriptor
sd_listen_fds (3)- Check for file descriptors passed by the init system.
http://0pointer.de/public/systemd-man/sd_listen_fds.html
I wrote simple patch that close the extra sockets. It's tested and works
fine. You'll maybe want to move that function to different place and/or
change wording of error messages.
Michal
diff -up dovecot-2.0.20/src/master/service-listen.c.systemdfix dovecot-2.0.20/src/master/service-listen.c
--- dovecot-2.0.20/src/master/service-listen.c.systemdfix 2011-12-13 12:38:27.0 +0100
+++ dovecot-2.0.20/src/master/service-listen.c 2012-04-13 18:29:37.724290656 +0200
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#define MIN_BACKLOG 4
#define MAX_BACKLOG 511
@@ -231,16 +232,90 @@ static int service_listen(struct service
return ret;
}
+static int get_socket_info(int fd, unsigned int *family, unsigned int *port)
+{
+ union sockaddr_union {
+ struct sockaddr sa;
+ struct sockaddr_in in4;
+ struct sockaddr_in6 in6;
+ } sockaddr;
+ socklen_t l;
+
+ if (port) *port = -1;
+ if (family) *family = -1;
+
+ memset(&sockaddr, 0, sizeof(sockaddr));
+ l = sizeof(sockaddr);
+
+ if (getsockname(fd, &sockaddr.sa, &l) < 0)
+ return -errno;
+
+ if (family) *family = sockaddr.sa.sa_family;
+ if (port) {
+ if (sockaddr.sa.sa_family == AF_INET) {
+ if (l < sizeof(struct sockaddr_in))
+return -EINVAL;
+
+ *port = ntohs(sockaddr.in4.sin_port);
+ } else {
+ if (l < sizeof(struct sockaddr_in6))
+return -EINVAL;
+
+ *port = ntohs(sockaddr.in6.sin6_port);
+ }
+ }
+ return 0;
+}
+
int services_listen(struct service_list *service_list)
{
struct service *const *services;
int ret = 1, ret2;
array_foreach(&service_list->services, services) {
ret2 = service_listen(*services);
if (ret2 < ret)
ret = ret2;
}
+
+ static int sd_fds = -1;
+ int fd, fd_max;
+
+ if (sd_fds < 0) {
+ sd_fds = sd_listen_fds(0);
+ if (sd_fds == -1) {
+ i_error("sd_listen_fds() failed: %m");
+ return -1;
+ }
+ }
+
+ fd_max = SD_LISTEN_FDS_START + sd_fds - 1;
+ for (fd = SD_LISTEN_FDS_START; fd <= fd_max; fd++) {
+ if (sd_is_socket_inet(fd, 0, SOCK_STREAM, 1, 0) > 0) {
+ int found = FALSE;
+ unsigned int port, family;
+ get_socket_info(fd, &family, &port);
+
+ array_foreach(&service_list->services, services) {
+ struct service_listener *const *listeners;
+array_foreach(&(*services)->listeners, listeners) {
+ struct service_listener *l = *listeners;
+ if (l->type != SERVICE_LISTENER_INET) continue;
+ if (l->set.inetset.set->port == port && l->set.inetset.ip.family == family) {
+ found = TRUE;
+ break;
+ }
+}
+if (found) break;
+ }
+ if (!found) {
+i_error("we've got socket that listens on port %d, but it's not configured. Closing.",port);
+if (shutdown(fd,SHUT_RDWR) < 0 && errno != ENOTCONN) i_error("shutdown() failed: %m");
+close(fd);
+ }
+ }
+ }
+
return ret;
}
Re: [Dovecot] dovecot and systemd
On 05/04/2012 08:54 PM, Timo Sirainen wrote: On 16.4.2012, at 12.55, Michal Hlavinka wrote: I wrote simple patch that close the extra sockets. It's tested and works fine. You'll maybe want to move that function to different place and/or change wording of error messages. I committed it to v2.1 now with a couple of changes. One is that it doesn't actually close the fd, but instead puts /dev/null into it. I think otherwise Dovecot might use that fd to something else and the check would later fail again and close the wrong fd. http://hg.dovecot.org/dovecot-2.1/rev/4a3bf567da54 Thanks. I tested it, but it does not work because of the ret == 0 check before services_verify_systemd. ret is usually 1 Michal
[Dovecot] /var/mail/ and mail group privileges
Hi Timo, I'm facing problem with mail group privileges (again), because I've heard a few complains. I was looking at old emails and list archives, but still does not know the answer. In default (fedora/rhel) setup mail group and 0660 privileges are used. This means that when mail_location = mbox:~/mail:INBOX=/var/mail/%u is used, dovecot fails with first (and only first) attempt to select inbox (imap) or login (pop3). Shouldn't mkdir and chown make together a transaction? When it fails just for first time, it confuses some admins (this is the reason why I'm getting complains (bug reports) just because missing/wrong configuration). I think it a) should work even for first connection (ignore chown failure) or b)it should not work for following connection, so the behavior should be more consistent. Also it seems unclear what configuration option is required for making this work in new dovecot versions where configuration is split to mail_privileged_group and mail_access_groups. I see that after reading documentation in 10-mail.conf, some admins expects mail_privileged_group to be enough while mail_access_group is required to prevent fchown failure. Would it be possible to explicitly mention in the config file what option is required? I can add patch with this to our rpm, but we always prefer to be as close to the upstream as possible. Thanks Michal
Re: [Dovecot] /var/mail/ and mail group privileges
On Tuesday, January 04, 2011 00:47:16 Timo Sirainen wrote: > On 3.1.2011, at 19.15, Michal Hlavinka wrote: > > Shouldn't mkdir and chown make together a transaction? When it fails just > > for first time, it confuses some admins (this is the reason why I'm > > getting complains (bug reports) just because missing/wrong > > configuration). I think it a) should work even for first connection > > (ignore chown failure) or b)it should not work for following connection, > > so the behavior should be more consistent. > > Sounds reasonable, yes. (Not such which one, a or b.) I should probably do > something about it, but it's still about how to handle an error condition, > so not a hugely important thing. I think a) is better for lazy admins, but b) is more correct, because other way it's (a little bit) harder to find out this error - having wrong permissions in situations when group is really required.
Re: [Dovecot] v2.0.9 released
On Thursday 13 of January 2011 13:21:26 Timo Sirainen wrote: > http://dovecot.org/releases/2.0/dovecot-2.0.9.tar.gz > http://dovecot.org/releases/2.0/dovecot-2.0.9.tar.gz.sig > > I'm still lagging behind in my email, but I guess it's time to release > v2.0.9 anyway. I've noticed that for some unknown reason doc/wiki/LDA.Sieve.txt is "empty" this time despite wiki.dovecot.org/LDA/Sieve still has its content. Not that important, just to let you know.
Re: [Dovecot] /var/mail/ and mail group privileges
On Thursday 10 of February 2011 02:54:39 Timo Sirainen wrote: > On Mon, 2011-01-10 at 14:08 +0100, Michal Hlavinka wrote: > > On Tuesday, January 04, 2011 00:47:16 Timo Sirainen wrote: > > > On 3.1.2011, at 19.15, Michal Hlavinka wrote: > > > > Shouldn't mkdir and chown make together a transaction? When it > > > > fails just for first time, it confuses some admins (this is the > > > > reason why I'm getting complains (bug reports) just because > > > > missing/wrong > > > > configuration). I think it a) should work even for first > > > > connection > > > > (ignore chown failure) or b)it should not work for following > > > > connection, so the behavior should be more consistent. > > > > I think a) is better for lazy admins, but b) is more correct, because > > other way it's (a little bit) harder to find out this error - having > > wrong permissions in situations when group is really required. > > I implemented a) a while ago. yes, I've noticed it. Thanks
Re: [Dovecot] systemd socket and service
> > > 2) Does dovecot.service required to use dovecot lmtp, or it may be > > > stoppped (i not often check my mails via client, but have many incoming > > > mails some time) > > > > I don't understand. If you want LMTP enabled, you also need to list its > > socket to dovecot.socket. LMTP is executed in a similar way to > > IMAP/POP3. (If you want LMTP via UNIX socket, I don't really know the > > answer to that. Does systemd support listening on UNIX sockets? Maybe > > it requires patching Dovecot more.) > > I'm not fully understand how can i do that and not lost my changes to > dovecot.socket when the packages updates and file has been rewritten... packages should install systemd socket/service files in /lib/systemd/ if you want to change any file, you should copy it to /etc/systemd/... and modify it there. systemd prefers files in /etc/systemd over those in /lib/systemd
[Dovecot] Regression in settings-parser.c (dovecot 2.0.11)
Hi, one Fedora user sees regression in dovecot 2.0.11 (compared to prev. 2.0.9). There was change recently: http://hg.dovecot.org/dovecot-2.0/diff/bc77e80947c0/src/lib-settings/settings-parser.c which adds call to settings_find_key_nth(, &parent_def,...). This function can set parent_def to NULL, but there is no check for this situation in the code. So on next line if (parent_def->type !=... dovecot crashes. We've tested simple fix: if (parent_def==NULL) return FALSE; and everything was working again. Michal Backtrace of the crash: Program received signal SIGSEGV, Segmentation fault. settings_find_key_nth (ctx=0x99e4050, key=0x99c4330 "plugin//etc", n=0xbff9bdac, def_r=0xbff9bda8, link_r=0xbff9bda4) at settings-parser.c:696 696 if (parent_def->type != SET_STRLIST) (gdb) p parent_def $1 = (const struct setting_define *) 0x0 (gdb) bt #0 settings_find_key_nth (ctx=0x99e4050, key=0x99c4330 "plugin//etc", n=0xbff9bdac, def_r=0xbff9bda8, link_r=0xbff9bda4) at settings-parser.c:696 #1 0x004f9ce5 in settings_find_key_nth (ctx=0x99e4050, key=0x99c4318 "plugin//etc/dovecot", n=0xbff9be1c, def_r=0xbff9be18, link_r=0xbff9be14) at settings-parser.c:693 #2 0x004f9ce5 in settings_find_key_nth (ctx=0x99e4050, key=0x99c42f8 "plugin//etc/dovecot/users", n=0xbff9beb4, def_r=0xbff9bebc, link_r=0xbff9beb8) at settings-parser.c:693 #3 0x004f94fd in settings_parse_keyvalue (ctx=0x99e4050, key=0x99c42f8 "plugin//etc/dovecot/users", value=0x99c42f2 "yes") at settings-parser.c:760 #4 0x004fa270 in settings_parse_line (ctx=0x99e4050, line=0x99c42d8 "plugin//etc/dovecot/users=yes") at settings-parser.c:862 #5 0x00dededa in set_line (ctx=0x99cd468, input=0xbff9c100, user_r=0xbff9c04c, error_r=0xbff9c0fc) at mail-storage-service.c:134 #6 user_reply_handle (ctx=0x99cd468, input=0xbff9c100, user_r=0xbff9c04c, error_r=0xbff9c0fc) at mail-storage-service.c:227 #7 mail_storage_service_lookup (ctx=0x99cd468, input=0xbff9c100, user_r=0xbff9c04c, error_r=0xbff9c0fc) at mail-storage-service.c:843 #8 0x00deeaae in mail_storage_service_lookup_next (ctx=0x99cd468, input=0xbff9c100, user_r=0xbff9c0ac, mail_user_r=0xbff9c0a8, error_r=0xbff9c0fc) at mail-storage-service.c:968 #9 0x0805f2e7 in client_create_from_input (input=, ---Type to continue, or q to quit--- login_client=0x99ce810, fd_in=11, fd_out=11, input_buf=0xbff9c0e0, error_r=0xbff9c0fc) at main.c:202 #10 0x0805f5dd in login_client_connected (client=0x99ce810, username=0x99c409b "sjoerd", extra_fields=0x99c4110) at main.c:267 #11 0x0051606f in master_login_auth_finish (client=0x99ce810, auth_args=) at master-login.c:206 #12 0x005163c2 in master_login_auth_callback (auth_args=0x99c410c, errormsg=0x0, context=0x99ce810) at master-login.c:374 #13 0x00516d3e in master_login_auth_input_user (auth=0x99cdcd8) at master-login-auth.c:239 #14 master_login_auth_input (auth=0x99cdcd8) at master-login-auth.c:359 #15 0x0052cc72 in io_loop_call_io (io=0x99cea10) at ioloop.c:384 #16 0x0052ded3 in io_loop_handler_run (ioloop=0x99cc390) at ioloop-epoll.c:213 #17 0x0052cbf0 in io_loop_run (ioloop=0x99cc390) at ioloop.c:405 #18 0x005181fb in master_service_run (service=0x99cc2e0, callback=0x805f100 ) at master-service.c:478 #19 0x0805fb0d in main (argc=1, argv=0xbff9c4c4) at main.c:375
Re: [Dovecot] Regression in settings-parser.c (dovecot 2.0.11)
On Saturday, March 26, 2011 01:02:04 Timo Sirainen wrote:
> On Fri, 2011-03-25 at 09:57 +0100, Michal Hlavinka wrote:
> > Hi,
> >
> > one Fedora user sees regression in dovecot 2.0.11 (compared to prev.
> > 2.0.9). There was change recently:
> > http://hg.dovecot.org/dovecot-2.0/diff/bc77e80947c0/src/lib-settings/settings-parser.c
> > which adds call to settings_find_key_nth(, &parent_def,...). This
> > function can set parent_def to NULL, but
> > there is no check for this situation in the code. So on next line if
> > (parent_def->type !=... dovecot crashes.
> > We've tested simple fix: if (parent_def==NULL) return FALSE; and everything
> > was working again.
>
> Well, yes, there is a bug. But how is this happening?
>
> > #3 0x004f94fd in settings_parse_keyvalue (ctx=0x99e4050,
> > key=0x99c42f8 "plugin//etc/dovecot/users", value=0x99c42f2 "yes")
>
> Where is this "plugin//etc/dovecot/users=yes" coming from? Is it from a
> userdb lookup that returns a broken setting? If Dovecot is somehow
> internally setting this, there's a bug somewhere.
User reported he uses original configuration with minimal changes:
"""My configuration differs only slightly from what the RPM delivers. Instead of
using the file auth-system.conf.ext, I use a file with the following content:
passdb {
driver = passwd-file
args = username_format=%u /etc/dovecot/users
}
userdb {
driver = passwd
args = username_format=%u /etc/dovecot/users
}
"""""
Re: [Dovecot] coredump in dovecot 2.0.11
On Tuesday, April 12, 2011 21:27:11 k b wrote: > Will check as soon as there is a package for fedora 14. > Usually there is updated dovecot package in updates-testing repository next working day after release, but it seems I've built new package, but forgot to push it to repository. I've pushed it to updates-testing repository just a few minutes ago. It should be available within 24 hours, then you can update dovecot using (as root): yum update --enablerepo=updates-testing dovecot I don't know what's the problem with abrt, I'll ask its maintainers PS:for getting backtrace from gdb, you need core file (the one abrt deletes), but that backtrace would be useless, you need to install debuginfo symbols first, using (as root): debuginfo-install dovecot
Re: [Dovecot] coredump in dovecot 2.0.11
On Friday, April 15, 2011 08:31:20 Michal Hlavinka wrote: > On Tuesday, April 12, 2011 21:27:11 k b wrote: > > Will check as soon as there is a package for fedora 14. > > > Usually there is updated dovecot package in updates-testing > repository next working day after release, but it seems I've built > new package, but forgot to push it to repository. > > I've pushed it to updates-testing repository just a few minutes ago. > It should be available within 24 hours, then you can update dovecot > using (as root): > > yum update --enablerepo=updates-testing dovecot > > I don't know what's the problem with abrt, I'll ask its maintainers > > PS:for getting backtrace from gdb, you need core file (the one abrt deletes), > but that backtrace would be useless, you need to install debuginfo symbols > first, using (as root): > > debuginfo-install dovecot I've just asked abrt maintainer. > Corrupted or bad crash /var/spool/abrt/ccpp-1302628582-11711 (res:1), deleting This message is misleading, because "res:1" means duplicate, so it's not bad nor corrupted crash, but coredump should be already stored in different directory. How can you find it? Try: grep -r dovecot /var/spool/abrt/*/component it'll tell you what directory contains dovecot's crash. For example: /var/spool/abrt/ccpp-1302856889-1869/compoment:dovecot so core file would be: /var/spool/abrt/ccpp-1302856889-1869/coredump Before gdb,you need to install debug info symbols: debuginfo-install dovecot and then, you can use: gdb /usr/libexec/dovecot/imap /var/spool/abrt/ccpp-1302856889-1869/coredump bt full
Re: [Dovecot] Managesieve and Dovecot from ATRPM - Still no luck
> Hi list > I'm still trying to get managesieve running on centos x64 with the > packages from atrpm. I used the 1.2.9 rpms (also rebuilt with the > lastet managesieve patches) but I'm always getting the same error when > trying to compile managesieve try to rebuild official src.rpm package for Fedora 12, not the one from atrpm, afaik it should work.
[Dovecot] dovecot 2.0 fails self-tests
Hi, is it expected that dovecot 2.0.beta4 pass all of it's self-tests or some failures are normal? I've tried make check and everything passed up to this test: ... message_date_parse(7) : ok 0 / 8 tests failed test-message-decoder.c:67: Assert failed: message_decoder_decode_next_block(ctx, &input, &output) test-message-decoder.c:78: Assert failed: output.size == 3 test-message-decoder.c:84: Assert failed: output.size == 14 test-message-decoder.c:85: Assert failed: memcmp(output.data, " bar", 14) == 0 message decoder .. : FAILED 1 / 1 tests failed Regards, Michal Hlavinka
[Dovecot] Any info about 1.2->2.0 migration ?
Hi, there are few documents on the wiki ( http://wiki.dovecot.org/Upgrading ) about migration between old versions. Is there any document for 1.2->2.0 or list of configuration changes (especially the missing ones) in 2.0? Regards, Michal Hlavinka
[Dovecot] 2.0 FTBFS since sqlpool changes when --with-sql=plugin is used
Hi, yesterday lib-sql got driver-sqlpool with some changes in Makefile.am, but these changes in makefile works only for --with-sql=yes. When --with-sql=plugin is used build fails with: libtool --tag=CC --mode=link gcc -std=gnu99 -O2 -g -pipe -Wall -Wp,- D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 - m64 -mtune=generic -Wall -W -Wmissing-prototypes -Wmissing-declarations - Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -Wstrict- aliasing=2 -o checkpassword-reply checkpassword-reply.o ../../src/lib- dovecot/libdovecot.la -lrt libtool: link: gcc -std=gnu99 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 - fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic - Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar- subscripts -Wformat=2 -Wbad-function-cast -Wstrict-aliasing=2 -o .libs/auth auth.o auth-cache.o auth-client-connection.o auth-master-connection.o mech- otp-skey-common.o mech-plain-common.o auth-penalty.o auth-request.o auth- request-handler.o auth-settings.o auth-stream.o auth-worker-client.o auth- worker-server.o db-checkpassword.o db-sql.o db-passwd-file.o main.o mech.o mech-anonymous.o mech-plain.o mech-login.o mech-cram-md5.o mech-digest-md5.o mech-external.o mech-gssapi.o mech-ntlm.o mech-otp.o mech-skey.o mech-rpa.o mech-apop.o mech-winbind.o passdb.o passdb-blocking.o passdb-bsdauth.o passdb- cache.o passdb-checkpassword.o passdb-passwd.o passdb-passwd-file.o passdb- pam.o passdb-shadow.o passdb-sia.o passdb-vpopmail.o passdb-sql.o userdb.o userdb-blocking.o userdb-checkpassword.o userdb-nss.o userdb-passwd.o userdb- passwd-file.o userdb-prefetch.o userdb-static.o userdb-vpopmail.o userdb-sql.o db-ldap.o passdb-ldap.o userdb-ldap.o -Wl,--export-dynamic libpassword.a ../lib-ntlm/libntlm.a ../lib-otp/libotp.a ../../src/lib-sql/.libs/libsql.a ../../src/lib-dovecot/.libs/libdovecot.so -lcrypt -lpam -ldl -lrt -Wl,-rpath - Wl,/usr/lib64/dovecot libtool: link: gcc -std=gnu99 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 - fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic - Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar- subscripts -Wformat=2 -Wbad-function-cast -Wstrict-aliasing=2 -o .libs/checkpassword-reply checkpassword-reply.o ../../src/lib- dovecot/.libs/libdovecot.so -ldl -lrt -Wl,-rpath -Wl,/usr/lib64/dovecot ../../src/lib-sql/.libs/libsql.a(sql-api.o): In function `sql_init': /home/mhlavink/cvsf/dovecot/devel/dovecot-2.0.beta4/src/lib-sql/sql-api.c:70: undefined reference to `driver_sqlpool_init' Regards, Michal Hlavinka
Re: [Dovecot] 2.0 FTBFS since sqlpool changes when --with-sql=plugin is used
On Wednesday, May 05, 2010 09:24:13 Michal Hlavinka wrote: > Hi, > > yesterday lib-sql got driver-sqlpool with some changes in Makefile.am, but > these changes in makefile works only for --with-sql=yes. When > --with-sql=plugin is used build fails with: > > libtool --tag=CC --mode=link gcc -std=gnu99 -O2 -g -pipe -Wall -Wp,- > D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 > - m64 -mtune=generic -Wall -W -Wmissing-prototypes -Wmissing-declarations > - Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast > -Wstrict- aliasing=2 -o checkpassword-reply checkpassword-reply.o > ../../src/lib- dovecot/libdovecot.la -lrt > libtool: link: gcc -std=gnu99 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 - > fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic > - Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith > -Wchar- subscripts -Wformat=2 -Wbad-function-cast -Wstrict-aliasing=2 -o > .libs/auth auth.o auth-cache.o auth-client-connection.o > auth-master-connection.o mech- otp-skey-common.o mech-plain-common.o > auth-penalty.o auth-request.o auth- request-handler.o auth-settings.o > auth-stream.o auth-worker-client.o auth- worker-server.o > db-checkpassword.o db-sql.o db-passwd-file.o main.o mech.o > mech-anonymous.o mech-plain.o mech-login.o mech-cram-md5.o > mech-digest-md5.o mech-external.o mech-gssapi.o mech-ntlm.o mech-otp.o > mech-skey.o mech-rpa.o mech-apop.o mech-winbind.o passdb.o > passdb-blocking.o passdb-bsdauth.o passdb- cache.o passdb-checkpassword.o > passdb-passwd.o passdb-passwd-file.o passdb- pam.o passdb-shadow.o > passdb-sia.o passdb-vpopmail.o passdb-sql.o userdb.o userdb-blocking.o > userdb-checkpassword.o userdb-nss.o userdb-passwd.o userdb- passwd-file.o > userdb-prefetch.o userdb-static.o userdb-vpopmail.o userdb-sql.o db-ldap.o > passdb-ldap.o userdb-ldap.o -Wl,--export-dynamic libpassword.a > ../lib-ntlm/libntlm.a ../lib-otp/libotp.a ../../src/lib-sql/.libs/libsql.a > ../../src/lib-dovecot/.libs/libdovecot.so -lcrypt -lpam -ldl -lrt > -Wl,-rpath - Wl,/usr/lib64/dovecot > libtool: link: gcc -std=gnu99 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 - > fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic > - Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith > -Wchar- subscripts -Wformat=2 -Wbad-function-cast -Wstrict-aliasing=2 -o > .libs/checkpassword-reply checkpassword-reply.o ../../src/lib- > dovecot/.libs/libdovecot.so -ldl -lrt -Wl,-rpath -Wl,/usr/lib64/dovecot > ../../src/lib-sql/.libs/libsql.a(sql-api.o): In function `sql_init': > /home/mhlavink/cvsf/dovecot/devel/dovecot-2.0.beta4/src/lib-sql/sql-api.c:7 > 0: undefined reference to `driver_sqlpool_init' > > Regards, > Michal Hlavinka because libsql.a need driver_sqlpool_init it seems this must be used always, so I've just moved driver-sqlpool.c file from if ! PLUGIN driver_sources to libsql_la_SOURCES (see attached patch) and it builds now. diff -up dovecot-2.0.beta4/src/lib-sql/Makefile.am.betahotfix dovecot-2.0.beta4/src/lib-sql/Makefile.am --- dovecot-2.0.beta4/src/lib-sql/Makefile.am.betahotfix 2010-05-05 04:00:03.0 +0200 +++ dovecot-2.0.beta4/src/lib-sql/Makefile.am 2010-05-05 11:34:17.286805721 +0200 @@ -38,13 +38,13 @@ if ! SQL_PLUGINS driver_sources = \ driver-mysql.c \ driver-pgsql.c \ - driver-sqlpool.c \ driver-sqlite.c endif libsql_la_SOURCES = \ $(dist_sources) \ - $(driver_sources) + $(driver_sources) \ + driver-sqlpool.c nodist_libsql_la_SOURCES = sql-drivers-register.c if SQL_PLUGINS
[Dovecot] dovecot 2.0 vs. SELinux
Hi,
we were modifying old SELinux rules for dovecot 2.0. Everything seems ok, only
one report seems odd:
"SELinux is preventing /usr/sbin/dovecot "write" access on dovecot.conf."
Looking at strace output, dovecot tries to use socket on
/etc/dovecot/dovecot.conf which is regular file and no socket:
...
geteuid() = 0
getegid() = 0
open("/dev/null", O_WRONLY) = 3
fcntl(3, F_GETFD) = 0
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
socket(PF_FILE, SOCK_STREAM, 0) = 4
fcntl(4, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK)= 0
connect(4, {sa_family=AF_FILE, path="/var/run/dovecot/config"}, 110) = -1
ECONNREFUSED (Connection refused)
close(4)= 0
socket(PF_FILE, SOCK_STREAM, 0) = 4
fcntl(4, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK)= 0
connect(4, {sa_family=AF_FILE, path="/etc/dovecot/dovecot.conf"}, 110) = -1
ECONNREFUSED (Connection refused)
close(4)= 0
nanosleep({0, 7000}, NULL) = 0
socket(PF_FILE, SOCK_STREAM, 0) = 4
fcntl(4, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK)= 0
connect(4, {sa_family=AF_FILE, path="/etc/dovecot/dovecot.conf"}, 110) = -1
ECONNREFUSED (Connection refused)
close(4)= 0
nanosleep({0, 9000}, NULL) = 0
socket(PF_FILE, SOCK_STREAM, 0) = 4
fcntl(4, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK)= 0
connect(4, {sa_family=AF_FILE, path="/etc/dovecot/dovecot.conf"}, 110) = -1
ECONNREFUSED (Connection refused)
close(4)= 0
nanosleep({0, 8000}, NULL) = 0
...
(tries to connect 14x)
traceback for connect causing this selinux denial is:
connect
net_connect_unix : lib/network.c #246
net_connect_unix_with_retries : lib/network.c : #255
master_service_open_config : lib-master/master-service-settings.c #157
master_service_settings_read : lib-master/master-service-settings.c #302
master_settings_read : master/main.c
main : master/main.c
Does anyone know what happens here? Why dovecot tries to use regular file
dovecot.conf as socket? There is probably some magic in it (from my pov) which
I don't understand.
Regards,
Michal Hlavinka
Re: [Dovecot] dovecot 2.0 vs. SELinux
On Friday 14 of May 2010 17:42:25 Timo Sirainen wrote: > On 14.5.2010, at 14.10, Michal Hlavinka wrote: > > Looking at strace output, dovecot tries to use socket on > > > /etc/dovecot/dovecot.conf which is regular file and no socket: > Yeah, it was less code to do it that way.. But since it causes problems, > added more code: http://hg.dovecot.org/dovecot-2.0/rev/7bb35ad5e80e thanks, it fixed it
Re: [Dovecot] Dovecot 2.0 HG 11267: Crash on THREAD
On Wednesday, May 26, 2010 18:39:26 Timo Sirainen wrote: > On Thu, 2010-05-06 at 22:15 +0200, Frode Nordahl wrote: > > Hello, > > > > The following IMAP command crashes the latest version of Dovecot > > (regardless of format or contents of mailbox): . THREAD REFS US-ASCII > > ALL > > THREAD works nowadays with recent hg, right? (Maybe beta5 too, I'm not > sure.) yes, I was able to reproduce this and the fix you've commited fixed it
[Dovecot] post 2.0rc1 compilation issue
Hi, I was just updating dovecot to nightly snapshot for Fedora rawhide, but got following issue: fts-backend-solr.c: In function 'fts_box_name_get_root': fts-backend-solr.c:60: error: 'NAMESPACE_FLAG_INBOX' undeclared (first use in this function) fts-backend-solr.c:60: error: (Each undeclared identifier is reported only once and once again on line 750 seems the change http://hg.dovecot.org/dovecot-2.0/rev/07353259bb41 is not complete Michal
Re: [Dovecot] post 2.0rc1 compilation issue
On Wednesday, July 07, 2010 12:26:54 Michal Hlavinka wrote: > Hi, > > I was just updating dovecot to nightly snapshot for Fedora rawhide, but got > following issue: > fts-backend-solr.c: In function 'fts_box_name_get_root': > fts-backend-solr.c:60: error: 'NAMESPACE_FLAG_INBOX' undeclared (first use > in this function) > fts-backend-solr.c:60: error: (Each undeclared identifier is reported only > once > > and once again on line 750 > > seems the change http://hg.dovecot.org/dovecot-2.0/rev/07353259bb41 is not > complete > > Michal also make check fails for dsync: make[3]: Entering directory `/home/mhlavink/cvsf/dovecot/devel/dovecot-2.0.rc1/src/dsync' for bin in test-dsync-brain test-dsync-brain-msgs test-dsync-proxy test-dsync- proxy-server-cmd; do \ if ! /bin/sh ../../run-test.sh ./$bin; then exit 1; fi; \ done dsync brain .. : ok dsync brain full . : ok 0 / 2 tests failed ==769== Invalid read of size 1 ==769==at 0x405E60: dsync_worker_has_failed (dsync-worker.c:271) ==769==by 0x40488B: dsync_brain_deinit (dsync-brain.c:79) ==769==by 0x402C51: test_dsync_brain (test-dsync-brain.c:216) ==769==by 0x40636F: test_run_funcs (test-common.c:226) ==769==by 0x406490: test_run (test-common.c:234) ==769==by 0x3B0E01EC5C: (below main) (in /lib64/libc-2.12.so) ==769== Address 0x4c32540 is 256 bytes inside a block of size 480 free'd ==769==at 0x4A04D72: free (vg_replace_malloc.c:325) ==769==by 0x402C3D: test_dsync_brain (test-dsync-brain.c:214) ==769==by 0x40636F: test_run_funcs (test-common.c:226) ==769==by 0x406490: test_run (test-common.c:234) ==769==by 0x3B0E01EC5C: (below main) (in /lib64/libc-2.12.so) ==769== ==769== Invalid read of size 1 ==769==at 0x405E60: dsync_worker_has_failed (dsync-worker.c:271) ==769==by 0x404898: dsync_brain_deinit (dsync-brain.c:79) ==769==by 0x402C51: test_dsync_brain (test-dsync-brain.c:216) ==769==by 0x40636F: test_run_funcs (test-common.c:226) ==769==by 0x406490: test_run (test-common.c:234) ==769==by 0x3B0E01EC5C: (below main) (in /lib64/libc-2.12.so) ==769== Address 0x4c366a0 is 256 bytes inside a block of size 480 free'd ==769==at 0x4A04D72: free (vg_replace_malloc.c:325) ==769==by 0x402C47: test_dsync_brain (test-dsync-brain.c:215) ==769==by 0x40636F: test_run_funcs (test-common.c:226) ==769==by 0x406490: test_run (test-common.c:234) ==769==by 0x3B0E01EC5C: (below main) (in /lib64/libc-2.12.so) ==769== ==769== Invalid read of size 1 ==769==at 0x405E60: dsync_worker_has_failed (dsync-worker.c:271) ==769==by 0x40488B: dsync_brain_deinit (dsync-brain.c:79) ==769==by 0x4026B9: test_dsync_brain_full (test-dsync-brain.c:273) ==769==by 0x40636F: test_run_funcs (test-common.c:226) ==769==by 0x406490: test_run (test-common.c:234) ==769==by 0x3B0E01EC5C: (below main) (in /lib64/libc-2.12.so) ==769== Address 0x4c4c750 is 256 bytes inside a block of size 480 free'd ==769==at 0x4A04D72: free (vg_replace_malloc.c:325) ==769==by 0x4026A5: test_dsync_brain_full (test-dsync-brain.c:271) ==769==by 0x40636F: test_run_funcs (test-common.c:226) ==769==by 0x406490: test_run (test-common.c:234) ==769==by 0x3B0E01EC5C: (below main) (in /lib64/libc-2.12.so) ==769== ==769== Invalid read of size 1 ==769==at 0x405E60: dsync_worker_has_failed (dsync-worker.c:271) ==769==by 0x404898: dsync_brain_deinit (dsync-brain.c:79) ==769==by 0x4026B9: test_dsync_brain_full (test-dsync-brain.c:273) ==769==by 0x40636F: test_run_funcs (test-common.c:226) ==769==by 0x406490: test_run (test-common.c:234) ==769==by 0x3B0E01EC5C: (below main) (in /lib64/libc-2.12.so) ==769== Address 0x4c508b0 is 256 bytes inside a block of size 480 free'd ==769==at 0x4A04D72: free (vg_replace_malloc.c:325) ==769==by 0x4026AF: test_dsync_brain_full (test-dsync-brain.c:272) ==769==by 0x40636F: test_run_funcs (test-common.c:226) ==769==by 0x406490: test_run (test-common.c:234) ==769==by 0x3B0E01EC5C: (below main) (in /lib64/libc-2.12.so) ==769==
Re: [Dovecot] post 2.0rc1 compilation issue
On Wednesday, July 07, 2010 13:27:41 Timo Sirainen wrote: > On 7.7.2010, at 11.42, Michal Hlavinka wrote: > >> I was just updating dovecot to nightly snapshot for Fedora rawhide, but > >> got following issue: > >> fts-backend-solr.c: In function 'fts_box_name_get_root': > >> fts-backend-solr.c:60: error: 'NAMESPACE_FLAG_INBOX' undeclared (first > >> use in this function) > >> fts-backend-solr.c:60: error: (Each undeclared identifier is reported > >> only once > > Fixed: http://hg.dovecot.org/dovecot-2.0/rev/912a11f476cc confirmed > > ==769== Invalid read of size 1 > > ==769==at 0x405E60: dsync_worker_has_failed (dsync-worker.c:271) > > ==769==by 0x40488B: dsync_brain_deinit (dsync-brain.c:79) > > Fixed: http://hg.dovecot.org/dovecot-2.0/rev/056c3240a912 unfortunately still not enough, the same issue is on line 216 --- dovecot-2.0.rc1/src/dsync/test-dsync-brain.c.betahotfix 2010-07-02 04:00:08.0 +0200 +++ dovecot-2.0.rc1/src/dsync/test-dsync-brain.c2010-07-07 13:45:59.887603676 +0200 @@ -211,9 +211,9 @@ static void test_dsync_brain(void) test_assert(!test_dsync_worker_next_box_event(src_test_worker, &box_event)); test_assert(!test_dsync_worker_next_box_event(dest_test_worker, &box_event)); + dsync_brain_deinit(&brain); dsync_worker_deinit(&src_worker); dsync_worker_deinit(&dest_worker); - dsync_brain_deinit(&brain); test_end(); } with this change make check completes without any error
Re: [Dovecot] Dovecat crash signal 11 core dump
On Friday 09 of July 2010 03:07:00 Timo Sirainen wrote: > On 8.7.2010, at 19.57, Ray Kirby wrote: > > Jul 08 12:35:08 master: Error: service(auth): child 5516 killed with > > signal 11 (core dumped) > > Could you get a gdb backtrace? It said core dumped, so there should be one > in base_dir (doveconf base_dir). Then you can do: > > gdb /usr/local/libexec/dovecot/auth /usr/local/var/run/dovecot/core > bt full > > or something beware, if you have abrt enabled, it can steal/delete "wrong" core file (/var/log/messages): ... abrtd: Package 'dovecot' isn't signed with proper key ... abrtd: Corrupted or bad crash /var/cache/abrt/ccpp-1278658383-11426 (res:5), deleting We do not ship dovecot 2.0 in Fedora 12, so you have probably your own dovecot installed from source or3rd party rpm, in that case (if abrt steals/delete core file) check you have OpenGPGCheck = no ProcessUnpackaged = yes in your /etc/abrt/abrt.conf if not, change these values and restart abrtd daemon. You will find core file in /var/chache/abrt/ccpp-*/coredump second option is MakeCompatCore = yes in /etc/abrt/plugin/CCpp.conf which will keep core file in place - and add following line in the log/messages: abrt[11432]: saved core dump of pid 11426 to /var/run/dovecot/core.11426 (466944 bytes) NOTE:for official fedora packages, core dumps are always collected by abrt and accessible in /var/cache/abrt/ directory by default, so no need to change anything Michal
[Dovecot] lda with sieve crash
Hi,
my colleague found a crash in dovecot, while he was experimenting with
configuration for using dovecot with fetchmail. Backtrace can be found here:
http://pastebin.com/XQZqYBpH
Let me know if you need any other info.
Michal
# doveconf -n
# 20100716 (26936bdd3801+): /etc/dovecot/dovecot.conf
# OS: Linux 2.6.32
auth_debug = yes
auth_verbose = yes
info_log_path = /var/log/dovecot-info.log
log_path = /var/log/dovecot.log
mail_debug = yes
mail_location = maildir:~/Maildir
managesieve_notify_capability = mailto
managesieve_sieve_capability = comparator-i;octet comparator-i;ascii-casemap
fileinto reject envelope encoded-character vacation subaddress comparator-
i;ascii-numeric relational regex imap4flags copy include variables body
enotify environment mailbox date spamtest spamtestplus virustest
mbox_write_locks = fcntl
namespace {
hidden = no
inbox = yes
list = yes
location = maildir:~/Maildir
prefix = INBOX.
separator = .
subscriptions = yes
type = private
}
passdb {
driver = pam
}
plugin {
sieve = ~/.dovecot.sieve
sieve_dir = ~/sieve
}
service managesieve-login {
inet_listener sieve {
port = 4190
}
}
ssl_cert =
Re: [Dovecot] lda with sieve crash
On Friday, July 16, 2010 16:56:10 Timo Sirainen wrote: > > #0 mailbox_get_storage (box=0x0) at mail-storage.c:802 > > No locals. > > #1 0x7ff182bace34 in act_store_start (action=, > > > > aenv=0x153c848, tr_context=0x153c988) at sieve-actions.c:405 > > Looks like the cleanest fix is to just change lib-lda API still a bit..: > http://hg.dovecot.org/dovecot-2.0/rev/db22952d406a > > plus attached patch thanks, it works now
Re: [Dovecot] problem with ldap
And the same problem here, I can't get it compiled. (This is first time, I'm packaging 1.2 branch). It fails for ldap plugin (./configure --with-ldap=plugin is enough to reproduce this) linking src/auth/dovecot-auth >/bin/sh ../../libtool --tag=CC --mode=link gcc -std=gnu99 -g -O2 -Wall -W > -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith > -Wchar-subscripts -Wformat=2 -Wbad-function-cast -Wstrict-aliasing=2 > -I/usr/kerberos/include-export-dynamic -o dovecot-auth auth.o > auth-cache.o auth-client-connection.o auth-master-connection.o > auth-master-listener.o auth-request.o auth-request-handler.o auth-stream.o > auth-worker-client.o auth-worker-server.o db-checkpassword.o db-sql.o > db-passwd-file.o main.o mech.o mech-anonymous.o mech-plain.o mech-login.o > mech-cram-md5.o mech-digest-md5.o mech-ntlm.o mech-otp.o mech-skey.o > mech-rpa.o mech-apop.o mech-winbind.o otp-skey-common.o plain-common.o > passdb.o passdb-blocking.o passdb-bsdauth.o passdb-cache.o > passdb-checkpassword.o passdb-passwd.o passdb-passwd-file.o passdb-pam.o > passdb-shadow.o passdb-sia.o passdb-vpopmail.o passdb-sql.o userdb.o > userdb-blocking.o userdb-checkpassword.o userdb-nss.o userdb-passwd.o > userdb-passwd-file.o userdb-prefetch.o userdb-static.o userdb-vpopmail.o > userdb-sql.o mech-gssapi.o libpassword.a ../lib-settings/libsettings.a > ../lib-ntlm/libntlm.a ../lib-otp/libotp.a ../lib-sql/libsql.a > ../lib/liblib.a -lcrypt -lpam -export-dynamic -ldl fails with: > In function `passdbs_init': >/home/mhlavink/cvsf/dovecot/devel/dovecot-1.2.beta3/src/auth/passdb.c:230: > undefined reference to `passdb_ldap' userdb.o: In function `userdbs_init': >/home/mhlavink/cvsf/dovecot/devel/dovecot-1.2.beta3/src/auth/userdb.c:177: > undefined reference to `userdb_ldap' It seems that ldap sources are not compiled (and not linked). If I modify Makefile and add them (db-ldap.c passdb-ldap.c userdb-ldap.c ) to am__dovecot_auth_SOURCES_DIST list, it works fine. I have LDAP headers and libraries installed. >checking for ldap_init in -lldap... yes >checking ldap.h usability... yes >checking ldap.h presence... yes >checking for ldap.h... yes >checking for ldap_initialize in -lldap... yes >checking for ldap_start_tls_s in -lldap... yes ... >Install prefix .. : /usr/local >File offsets : 64bit >I/O loop method . : epoll >File change notification method . : inotify >Building with SSL support ... : yes (OpenSSL) >Building with IPv6 support .. : yes >Building with pop3 server ... : yes >Building with mail delivery agent .. : yes >Building with GSSAPI support : no >Building with user database modules . : static prefetch passwd passwd-file > checkpassword ldap (plugin) nss Building with password lookup modules : > passwd passwd-file shadow pam checkpassword ldap (plugin) It seems to me that configure/Makefile is not working or am I doing something wrong? Regards, Michal Hlavinka
Re: [Dovecot] v1.2.beta4 released
> http://dovecot.org/releases/1.2/beta/dovecot-1.2.beta4.tar.gz
> http://dovecot.org/releases/1.2/beta/dovecot-1.2.beta4.tar.gz.sig
>
> This release fixes a memory corruption bug related to MODSEQ handling in
> earlier v1.2 releases. Memory corruption means that it's a security bug
> and possibly exploitable. MODSEQ code is new in v1.2, so v1.1 and older
> releases are not affected.
>
Hi,
I can't get it compiled when I use --with-ldap=plugin for configure, is this
expected? ("[Dovecot] problem with ldap" thread contains details).
Regards,
Michal Hlavinka
Re: [Dovecot] trouble to start dovecot when ldap enabled
On Wednesday 17 June 2009 20:00:40 Jean-Noel Chardron wrote: > Timo Sirainen a écrit : > > On Wed, 2009-06-17 at 10:24 +0200, jean-Noël Chardron wrote: > >> Jun 17 10:15:24 aragon dovecot: Dovecot v1.2.rc3 starting up (core dumps > >> disabled) > >> Jun 17 10:15:24 aragon dovecot: Fatal: auth(default): Support not > >> compiled in for passdb driver 'ldap' > > > > This is fixed by rc5. > > Where can I get the rc5 ? I'll build fedora 11 dovecot packages as soon as all sources are available. Fedora packages need dovecot, sieve and managesieve sources, but the last one is still missing... For rc4 Stephan Bosch said there will be no managesieve release because some problems. So I'm curious if there is plan to release managesieve for rc5 dovecot? Regards, Michal Hlavinka
Re: [Dovecot] trouble to start dovecot when ldap enabled
On Thursday 18 June 2009 07:29:13 Timo Sirainen wrote: > On Jun 18, 2009, at 1:24 AM, Michal Hlavinka wrote: > > So I'm curious if there is plan to release > > managesieve for rc5 dovecot? > > rc3's managesieve patch works just fine with rc5. ok, thanks for the info... was this mentioned anywhere? Did I miss something?
Re: [Dovecot] trouble to start dovecot when ldap enabled
On Thursday 18 June 2009 07:50:22 Timo Sirainen wrote: > On Jun 18, 2009, at 1:43 AM, Michal Hlavinka wrote: > > On Thursday 18 June 2009 07:29:13 Timo Sirainen wrote: > >> On Jun 18, 2009, at 1:24 AM, Michal Hlavinka wrote: > >>> So I'm curious if there is plan to release > >>> managesieve for rc5 dovecot? > >> > >> rc3's managesieve patch works just fine with rc5. > > > > ok, thanks for the info... was this mentioned anywhere? Did I miss > > something? > > In general if an old patch applies without errors to a new code base, > it works fine. I heard that it applies fine and runs fine from another > guy who tried it. And also in RC stage the code is only getting bug > fixes. It's much less likely that anything will break even if you > apply an older patch. My guess is that managesieve rc1 patch would > still apply just fine with rc5. for me: 1 of 22 hunks failed (trimming the patch was quite easy) and error when building: error: macro "login_proxy_new" requires 6 arguments, but only 5 given it was missing ssl_flags argument and proxy_input change (change in login-proxy.h : proxy_callback_t) managesieve-proxy.c:305: warning: passing argument 1 of ‘proxy_input’ from incompatible pointer type managesieve-proxy.c:241: note: expected ‘struct istream *’ but argument is of type ‘struct managesieve_client *’ managesieve-proxy.c:305: error: too few arguments to function ‘proxy_input’
[Dovecot] dovecot 1.2rc5 fails to authenticate user via GSSAPI
Hi,
we're facing problem where dovecot 1.2rc5 is not able to authenticate user via
gssapi. (I'm forwarding information from red hat's bugzilla)
Steps to reproduce:
1. Install dovecot with kerberos support, create mailboxes for the client
2. Get initial credentials on client side
3. Attempt to log in via dovecot using gssapi
-> login failed
Client side
1. Email client displays: "[AUTHENTICATIONFAILED] Authentication failed."
2. klist before login shows:
Valid starting ExpiresService principal
06/18/09 20:01:01 06/19/09 20:01:01 krbtgt/re...@realm
3. klist after login attempt shows:
Valid starting ExpiresService principal
06/18/09 20:01:01 06/19/09 20:01:01 krbtgt/re...@realm
06/18/09 20:01:28 06/19/09 20:01:01 imap/mail.dom...@realm
Server side
1. /var/log/maillog:
dovecot: auth(default): gssapi(user,192.168.0.1): authn_name not authorized
dovecot: imap-login: Aborted login (auth failed, 1 attempts): user=,
method=GSSAPI, rip=192.168.0.1, lip=192.168.0.2, TLS
It is possible for the same user to login via other mechanisms.
The issue reproduced with different email clients. Evolution and a custom
java-based client were attempted.
example of dovecot.conf:
protocols = imap
mail_location = maildir:/home/virtual/%u/Maildir
protocol imap {
}
auth_krb5_keytab=/etc/dovecot.keytab
auth default {
mechanisms = gssapi
userdb static {
args = uid=vmail gid=vmail home=/home/virtual/%u
}
}
-
Exactly the same dovecot setup was working just fine with dovecot 1.1 series.
Authentication using kinit works just fine and kerberos infrastructure is
functioning well as I use kerberos auth for other services like apache and ssh
successfully.
/var/log/maillog with using auth_debug=yes can be found here:
https://bugzilla.redhat.com/attachment.cgi?id=348710
Regards,
Michal Hlavinka
Re: [Dovecot] dovecot 1.2rc5 fails to authenticate user via GSSAPI
On Wednesday 24 June 2009 17:15:31 Timo Sirainen wrote: > On Jun 24, 2009, at 9:38 AM, Michal Hlavinka wrote: > > we're facing problem where dovecot 1.2rc5 is not able to > > authenticate user via > > gssapi. (I'm forwarding information from red hat's bugzilla) > > I guess it has to be because of these patches: > > http://hg.dovecot.org/dovecot-1.2/rev/ff6378d7b209 > http://hg.dovecot.org/dovecot-1.2/rev/601e0382b442 > > Could you try reverting them and see if it helps? ok, I'll try it asap
Re: [Dovecot] dovecot 1.2rc5 fails to authenticate user via GSSAPI
On Thursday 25 June 2009 06:54:48 Michal Hlavinka wrote: > On Wednesday 24 June 2009 17:15:31 Timo Sirainen wrote: > > On Jun 24, 2009, at 9:38 AM, Michal Hlavinka wrote: > > > we're facing problem where dovecot 1.2rc5 is not able to > > > authenticate user via > > > gssapi. (I'm forwarding information from red hat's bugzilla) > > > > I guess it has to be because of these patches: > > > > http://hg.dovecot.org/dovecot-1.2/rev/ff6378d7b209 > > http://hg.dovecot.org/dovecot-1.2/rev/601e0382b442 > > > > Could you try reverting them and see if it helps? > > ok, I'll try it asap when I revert those two patches, it works
Re: [Dovecot] v1.2.rc7 released
On Sunday 28 June 2009 05:59:35 Timo Sirainen wrote: > http://dovecot.org/releases/1.2/rc/dovecot-1.2.rc7.tar.gz > http://dovecot.org/releases/1.2/rc/dovecot-1.2.rc7.tar.gz.sig > > I'll make RC releases daily now until v1.2.0 is released, which will be > either on Monday or Wednesday. Please test as much as possible. > > * Removed configure --with-deliver, --with-pop3d and --disable-ipv6 > parameters. > > + Improved permission related error messages. > - mbox: Don't write garbage to mbox if message doesn't have a body. > - virtual: Fixed saving messages with keywords. > - virtual: Fixed infinite looping bug. > - zlib: Fixed error handling. Hi, dovecot 1.2.rc7 fails to build ldap plugin. With reverted http://hg.dovecot.org/dovecot-1.2/rev/9214dd33a2a5 it works. configure command: + ./configure --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr --exec- prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc -- datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 -- libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib -- mandir=/usr/share/man --infodir=/usr/share/info 'INSTALL_DATA=install -c -p - m644' --enable-header-install --disable-static --with-pgsql --with-mysql -- with-sqlite --with-sql=plugin --with-sql-drivers --with-ssl=openssl --with- ssldir=/etc/pki/dovecot --with-ldap=plugin --with-gssapi=plugin rc7 configure output: Install prefix . : /usr File offsets ... : 64bit I/O polling : epoll I/O notifys : inotify SSL : yes (OpenSSL) GSSAPI . : plugin passdbs : passwd passwd-file shadow pam checkpassword ldap (plugin) sql : -bsdauth -sia -vpopmail userdbs : static prefetch passwd passwd-file checkpassword ldap (plugin) sql nss : -vpopmail SQL drivers : pgsql mysql sqlite (plugins) rc7 with reverted 9214dd33a2a5: Install prefix .. : /usr File offsets : 64bit I/O loop method . : epoll File change notification method . : inotify Building with SSL support ... : yes (OpenSSL) Building with GSSAPI support : plugin Building with user database modules . : static prefetch passwd passwd-file checkpassword ldap (plugin) sql nss Building with password lookup modules : passwd passwd-file shadow pam checkpassword ldap (plugin) sql Building with SQL drivers : pgsql mysql sqlite (plugins) There's no other difference in configure output. Regards, Michal Hlavinka
Re: [Dovecot] ManageSieve/dovecot 1.2.rc7
On Monday 29 June 2009 12:31:53 Edgar Fuß wrote:
> The ManageSieve patch for rc5 applies to rc7, but doesn't build.
>
> The problem is obvoiusly that
> dovecot-managesive/src/managesieve-login/client.c tests:
>
> #if CLIENT_LOGIN_IDLE_TIMEOUT_MSECS >= AUTH_REQUEST_TIMEOUT*1000
> # error client idle timeout must be smaller than authentication timeout
> #endif
>
> while dovecot/src/{pop3,imap}-login/client.c do the opposite test:
>
> #if CLIENT_LOGIN_IDLE_TIMEOUT_MSECS < AUTH_REQUEST_TIMEOUT*1000
> # error client idle timeout must be larger than authentication timeout
> #endif
>
> As I don't understand what this is about, I won't touch it.
this was recently changed:
http://hg.dovecot.org/dovecot-1.2/rev/1c91fa0d804b
so I've changed it this way and it seems, it works.
-#if CLIENT_LOGIN_IDLE_TIMEOUT_MSECS >= AUTH_REQUEST_TIMEOUT*1000
-# error client idle timeout must be smaller than authentication timeout
+#if CLIENT_LOGIN_IDLE_TIMEOUT_MSECS < AUTH_REQUEST_TIMEOUT*1000
+# error client idle timeout must be larger than authentication timeout
Michal
Re: [Dovecot] v1.2.0 released
> http://dovecot.org/releases/1.2/dovecot-1.2.0.tar.gz > http://dovecot.org/releases/1.2/dovecot-1.2.0.tar.gz.sig > > As promised. No changes since v1.2.rc8 (except packaged in OS X, since > CentOS 5 autotools didn't add support for configure --docdir). > Congratulation! Is gssapi auth problem fixed in this version or not yet? Regards, Michal Hlavinka
Re: [Dovecot] v1.2.0 released
On Thursday 02 July 2009 07:31:00 Timo Sirainen wrote: > On Jul 2, 2009, at 7:25 AM, Michal Hlavinka wrote: > > Is gssapi auth problem fixed in this version or not yet? > > If I fix it for you, I break it for someone else. I'd need to find out > what exacly is that patch doing wrong and how it should be fixed the > correct way. can I help you somehow with it? (unfortunately I don't how exactly gssapi works)
Re: [Dovecot] v1.2.0 released
> http://dovecot.org/releases/1.2/dovecot-1.2.0.tar.gz > http://dovecot.org/releases/1.2/dovecot-1.2.0.tar.gz.sig > > As promised. No changes since v1.2.rc8 (except packaged in OS X, since > CentOS 5 autotools didn't add support for configure --docdir). download page suggest using new dovecot sieve plugin. It's version 0.1.6 so I wonder how much stable and feature complete it is comparing to the old sieve plugin? Which one is better and why? Regards, Michal Hlavinka
Re: [Dovecot] dovecot 1.2rc5 fails to authenticate user via GSSAPI
On Wednesday 08 July 2009 03:06:08 Timo Sirainen wrote: > On Tue, 2009-07-07 at 20:29 -0400, Timo Sirainen wrote: > > On Tue, 2009-07-07 at 20:20 -0400, Timo Sirainen wrote: > > > On Wed, 2009-06-24 at 15:38 +0200, Michal Hlavinka wrote: > > > > dovecot: auth(default): gssapi(user,192.168.0.1): authn_name not > > > > authorized > > > > > > Can you try what it says with these patches: > > > > > > http://hg.dovecot.org/dovecot-1.2/rev/4172004c1958 > > > http://hg.dovecot.org/dovecot-1.2/rev/a5c5a912769e > > > > With those patches you also need auth_debug=yes to get everything > > logged. > > I guess this fixes it again: > http://hg.dovecot.org/dovecot-1.2/rev/f4ff64dd79a9 should I try it only with these 3 patches or even with the last one? http://hg.dovecot.org/dovecot-1.2/rev/5d9eab092e97
Re: [Dovecot] dovecot 1.2rc5 fails to authenticate user via GSSAPI
On Wednesday 08 July 2009 03:06:08 Timo Sirainen wrote: > On Tue, 2009-07-07 at 20:29 -0400, Timo Sirainen wrote: > > On Tue, 2009-07-07 at 20:20 -0400, Timo Sirainen wrote: > > > On Wed, 2009-06-24 at 15:38 +0200, Michal Hlavinka wrote: > > > > dovecot: auth(default): gssapi(user,192.168.0.1): authn_name not > > > > authorized > > > > > > Can you try what it says with these patches: > > > > > > http://hg.dovecot.org/dovecot-1.2/rev/4172004c1958 > > > http://hg.dovecot.org/dovecot-1.2/rev/a5c5a912769e > > > > With those patches you also need auth_debug=yes to get everything > > logged. > > I guess this fixes it again: > http://hg.dovecot.org/dovecot-1.2/rev/f4ff64dd79a9 We've tested dovecot with all four available patches (it means up to date mech-gssapi.c ) and it wokrs. Thanks!
Re: [Dovecot] dovecot 1.2rc5 fails to authenticate user via GSSAPI
> > > I guess this fixes it again: > > > http://hg.dovecot.org/dovecot-1.2/rev/f4ff64dd79a9 > > > > We've tested dovecot with all four available patches (it means up to date > > mech-gssapi.c ) and it wokrs. > > I've been talking with the main Heimdal guy and he thinks that kind of > checking is scary bad. > > One thing that should change at least is that gss_display_name() > shouldn't be passed to krb5_parse_name(). Instead gss_export_name() > should be used and its results checked and passed to krb5_parse_name() > (OpenSSH does this too). But I don't know if that would solve the > original problem that required me to add the patch mentioned above. > > One thing I'm not really sure about in Kerberos is, does both MIT and > Heimdal require that you are using system users and to have NSS set up > in a way that Kerberos code can look up users with getpw*() functions? I > think that's the main thing that krb5_kuserok() does that > gss_compare_name() doesn't. But does Kerberos do the same check > elsewhere and this isn't really a problem after all? If it doesn't check > user's existence elsewhere, maybe I could just use gss_export_name()s > and compare them instead of display names?.. Unfortunately my Kerberos knowledge is almost equal to zero, so I can't help with theory, sorry.
Re: [Dovecot] Released Sieve v0.1.11 and ManageSieve v0.11.8 for Dovecot v1.2.3
> Hello Dovecot users, Hi, > Apart from unfinished development of the date extension, this is a set > of bug-fix releases. A few portability issues were found, a few > stupidities were fixed and the ManageSieve proxy now also works with > TLS. Most notably, the include extension had an issue regarding the > expansion of $HOME in the personal include path. > > I've built a project site at: http://pigeonhole.dovecot.org > > Changelog Sieve v0.1.11: > > + Built skeleton implementation for the date extension (RFC5260). >It compiles, but it does not do anything useful yet. Therefore, it >is not part of the default compilation. > - Fixed ARM portability issues caused by char type not being signed >on that platform. Reading optional operands from a binary would >fail for action side effects. Also, an accidental mixup of an int >return type with bool caused the interpreter to continue on ARM >even though an error occured. > - Removed direct stdint.h includes to prevent portability issues. > - Fixed segfault bug in the handling of script open failures. > - Include: improved user error messages and system log messages. > - Fixed copy-paste mixup between sieve_after and sieve_before >settings in the LDA Sieve plugin. If only a sieve_after script was >active, nothing would have been executed. Patch by Mike Abbott. > - Include: fixed a bug in HOME substitution in the sieve_dir path. >Surfaced in ManageSieve. > > ... > > Have fun testing the new releases and don't hesitate to notify me when > there are problems. build process for Sieve fails when --with-unfinished-features option is set: ... make[2]: Entering directory `/home/mihl/myroot/job/cvsf/dovecot/devel/dovecot-1.2.3/dovecot-1.2- sieve-0.1.11' make[2]: *** No rule to make target `doc/man/sieve-filter.1', needed by `all- am'. Stop. without this it works. Regards, Michal Hlavinka
[Dovecot] % in Usernames (dovecot 1.1.18)
Hi, I'm forwarding feature request from one Fedora user: Shortly before suicide after migration to dbmail/postfix from Eudora Mailserver because we use % in Usernames as fallback and Apple-Mail does no Plaintext- Auth if CRAM-MD% was used before i installed dovecot as proxy BUT it allows no % in Username Please could be the following patch included? --- dovecot-1.1.18/src/master/master-settings.c 2009-07-27 03:56:32.0 +0200 +++ dovecot-1.1.18-patched/src/master/master-settings.c 2009-08-10 22:57:09.728065279 +0200 @@ -310,7 +310,7 @@ MEMBER(executable) PKG_LIBEXECDIR"/dovecot-auth", MEMBER(user) "root", MEMBER(chroot) "", - MEMBER(username_chars) "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@", + MEMBER(username_chars) "abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz01234567890...@%", MEMBER(username_translation) "", MEMBER(username_format) "", MEMBER(master_user_separator) "", Would it be possible or is there any reason why this is a wrong idea? Regards, Michal Hlavinka
[Dovecot] dovecot 1.2 and logging start failures
Hi, I've got report about issue when dovecot fails to start and there is no error logged (error goes only to stderr) situation: 1) dovecot is running 2) dovecot is automatically updated to new version (by yum update daemon), after update, dovecot is restarted (it's part of update script) 3) new dovecot fails to start (for whatever reason) result: dovecot not running and no error message has been logged because (at least some) errors were written to stderr only and not syslog another situation (original issue) was when dovecot was configured to listen for ipv4 and ipv6 connections. ipv6 support was disabled. After server reboot, dovecot failed to start, producing dovecot: Fatal: listen(::, 143) failed: Address already in use only to stderr, nothing in logs. Would it be possible to use syslog for error output sooner or there are any cons? Regards, Michal Hlavinka
Re: [Dovecot] dovecot 1.2 and logging start failures
On Monday 07 September 2009 04:18:06 Timo Sirainen wrote:
> On Tue, 2009-09-01 at 16:57 +0200, Michal Hlavinka wrote:
> > Would it be possible to use syslog for error output sooner or there are
> > any cons?
>
> http://hg.dovecot.org/dovecot-1.2/rev/eb4ea59e4657
>
Thanks for looking at this!
Unfortunately this does not work
backtrace:
(gdb) bt
#0 0x0034bca489d7 in _IO_vfprintf_internal (s=0x7fffe020,
format=, ap=0x7fffe350) at vfprintf.c:1580
#1 0x0034bca6f232 in _IO_vsnprintf (string=0x63f718 "listen(",
maxlen=, format=0x63f6e8 "listen(%s, %d) failed: Address
already in use", args=0x7fffe350)
at vsnprintf.c:120
#2 0x0042605c in t_noalloc_strdup_vprintf (format=0x63f6e8
"listen(%s, %d) failed: Address already in use", args=0x7fffe350,
size_r=0x7fffe22c) at strfuncs.c:120
#3 0x00426152 in p_strdup_vprintf (pool=0x63c780, format=0x42bd69
"listen(%s, %d) failed: %m", args=0x7fffe350) at strfuncs.c:139
#4 0x004266c2 in t_strdup_vprintf (format=0x42bd69 "listen(%s, %d)
failed: %m", args=0x7fffe350) at strfuncs.c:254
#5 0x004171c6 in syslog_handler (level=2, type=LOG_TYPE_FATAL,
format=0x42bd69 "listen(%s, %d) failed: %m", args=0x7fffe350) at
failures.c:298
#6 0x00417274 in i_syslog_fatal_handler (type=LOG_TYPE_FATAL,
status=89, fmt=0x42bd69 "listen(%s, %d) failed: %m", args=0x7fffe350) at
failures.c:311
#7 0x0040d783 in tee_fatal_handler (type=LOG_TYPE_FATAL, status=89,
fmt=0x42bd69 "listen(%s, %d) failed: %m", args=0x7fffe350) at main.c:152
#8 0x00416d87 in i_fatal (format=0x42bd69 "listen(%s, %d) failed:
%m") at failures.c:216
#9 0x00407616 in listener_array_listen_missing (proto=0x42bc64
"imap", listens_arr=0x647720, retry=false) at listener.c:335
#10 0x0040769d in listener_listen_missing (set=0x6474d8,
proto=0x42bc64 "imap", retry=false) at listener.c:346
#11 0x004077e1 in listeners_open_fds (old_set=0x0, retry=false) at
listener.c:371
#12 0x0040e50c in main (argc=1, argv=0x7fffe658) at main.c:649
reproducer:
listen for ipv4 and ipv6 connections on system, where ipv6 is disabled, start
dovecot:
Fatal: listen(::, 143) failed: Address already in use
Program received signal SIGSEGV, Segmentation fault.
Cheers,
Michal
(gdb) bt full
#0 0x0034bca489d7 in _IO_vfprintf_internal (s=0x7fffe020,
format=, ap=0x7fffe350) at vfprintf.c:1580
len =
string_malloced =
step0_jumps = {0, 3491, 3570, 6406, 6492, 2736, 2829, 5759, 3764, 3946,
4175, 1491, 1570, 1659, 1889, 1936, 3749, 3086, 5665, 5090, 6168, -557, 4254,
4343, 6127, -2814, 5387, 1748,
1817, 5680}
step3b_jumps = {0 , 1570, 0, 0, 1889, 1936, 3749,
3086, 5665, 5090, 6168, -557, 4254, 4343, 6127, -2814, 5387, 0, 0, 0}
is_negative =
alt = 0
space = 0
is_long_double = 0
step2_jumps = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4175, 1491, 1570, 1659,
1889, 1936, 3749, 3086, 5665, 5090, 6168, -557, 4254, 4343, 6127, -2814, 5387,
1748, 1817, 0}
the_arg = {pa_wchar = -1130298040 L'H', pa_int = -1130298040,
pa_long_int = 226502968648, pa_long_long_int = 226502968648, pa_u_int =
3164669256, pa_u_long_int = 226502968648,
pa_u_long_long_int = 226502968648, pa_double =
1.1190733549003374e-312, pa_long_double = , pa_string =
0x34bca10548 "",
pa_wstring = 0x34bca10548
L"\15130273400\31064564\13723644537\14334663166\31467141\15134657537\15431262147\35062563\13723644537\16335062547\15532272000\14431471145\16431271537\14533264564\14627657400\15135071157\14627674546\33064541\16035062547\16233664562\36272151\13723644537\14631262167\16433072541\16034674137\33472165\15034066141\16233671541\14532000164\16233671162\15733061400\14500065543\16433462566\16700062146\14631071157\31262562\16035671566\16433464562\13727600146\16434661157\13732661541\15134470166\13731472156\32664143\16434472163\14133264557\13727600170\16034671551\13731261541\11127600154\14534657517\15535665545\32671141\16431271537\34066552\14233257537\16434467163\16330673557\15332061537\16327657400\15531471164\15427667157\16231074000\15430261537\14734666554\16327657400\16235261545\14531657545\16633462564\16431263400\14132266141\16433462563\14531072000\14535062554\16327657400\14431264143\16534061537\15635267543\13727600164\14535467567\15733063162\14436000167\13735257562\14733467554\14733467554\15500072137\15634663563\16230200144\14527675147\14134472170\13700072143\16235071537\13731067564\14535067151\15430267162\15430266400\13730667554\14230271565\16327662554\31275151\16335062547\15530267160\15035062400\15427671145\31267151\15433060555\16427661557\33264562\14531661564\16231670164\16434000160\14131271150\14534657544\15630261564\16433062543\31270171\16331067145\16433462
Re: [Dovecot] dovecot 1.2 and logging start failures
On Monday 07 September 2009 17:48:13 Timo Sirainen wrote: > On Sep 7, 2009, at 6:01 AM, Michal Hlavinka wrote: > > On Monday 07 September 2009 04:18:06 Timo Sirainen wrote: > >> On Tue, 2009-09-01 at 16:57 +0200, Michal Hlavinka wrote: > >>> Would it be possible to use syslog for error output sooner or > >>> there are > >>> any cons? > >> > >> http://hg.dovecot.org/dovecot-1.2/rev/eb4ea59e4657 > > > > Thanks for looking at this! > > > > Unfortunately this does not work > > It worked in Ubuntu, but I guess these fix it: > > http://hg.dovecot.org/dovecot-1.2/rev/cc0d7c00c6ce > http://hg.dovecot.org/dovecot-1.2/rev/5f9782109fcf > confirmed, now it works thanks
[Dovecot] Capability info in hello message not complete?
Hi, one Fedora user complains about not some troubles after update to dovecot 1.2. He suspects wrong capability information given by dovecot 1.2 In dovecot.conf he uses imap_capability= option. While response to 'A CAPABILITY' respects imap_capability value, the capability info in hello message does not. for imap_capability=IMAP4 IMAP4rev1 ACL NAMESPACE CHILDREN SORT QUOTA THREAD=ORDEREDSUBJECT UNSELECT IDLE STARTTLS AUTH=PLAIN A CAPABILITY response is: * CAPABILITY IMAP4 IMAP4rev1 ACL NAMESPACE CHILDREN SORT QUOTA THREAD=ORDEREDSUBJECT UNSELECT IDLE STARTTLS AUTH=PLAIN but hello message is: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN] Dovecot ready. But it seems even when imap_capability is not used capability in hello message is not complete: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN] Dovecot ready. vs. * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH STARTTLS AUTH=PLAIN is this expected? Do you think capability information in hello message really can befool clients? Regards, Michal Hlavinka
Re: [Dovecot] Capability info in hello message not complete?
On Thursday 01 October 2009 15:15:09 Timo Sirainen wrote: > On Thu, 2009-10-01 at 14:59 +0200, Michal Hlavinka wrote: > > Hi, > > > > one Fedora user complains about not some troubles after update to dovecot > > 1.2. He suspects wrong capability information given by dovecot 1.2 > > > > In dovecot.conf he uses imap_capability= option. While response to 'A > > CAPABILITY' respects imap_capability value, the capability info in hello > > message does not. > > > > for imap_capability=IMAP4 IMAP4rev1 ACL NAMESPACE CHILDREN SORT QUOTA > > THREAD=ORDEREDSUBJECT UNSELECT IDLE STARTTLS AUTH=PLAIN > > I suppose he's using Dovecot as a proxy? Because Dovecot doesn't support > IMAP4 or THREAD=ORDEREDSUBJECT. yes, dovecot is used as proxy > > > but hello message is: > > * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE > > STARTTLS AUTH=PLAIN] Dovecot ready. > > Hmm. Yeah.. > > > But it seems even when imap_capability is not used capability in hello > > message is not complete: > > .. > > > is this expected? Do you think capability information in hello message > > really can befool clients? > > The capability in greeting message is short on purpose. It's only enough > capabilities to get client logged in. After login Dovecot sends an > updated full capability list to the client. It uses a few different > tricks to get most clients understand the change. > > So the only potential problem I see here is if client understands the > greeting capability and permanently remembers that the server supports > LITERAL+, ID and ENABLE after login but the destination server actually > doesn't. The other capabilities are relevant only before login. I'm not > entirely sure what, if anything, I should do about this. > > I'd anyway like to hear what exactly is the problem and with what > client, preferably with IMAP traffic logs showing what's happening > wrong. forwarded info: The imap-server is dbmail which supports "IMAP4 IMAP4rev1 ACL NAMESPACE CHILDREN SORT QUOTA THREAD=ORDEREDSUBJECT UNSELECT IDLE" and with dovecot version 1.1 it worked fine The problem sue is "LITERAL+" what dbmail does not support. The problem client was apple iphone
Re: [Dovecot] Capability info in hello message not complete?
On Tuesday 06 October 2009 15:35:20 Michal Hlavinka wrote: > On Thursday 01 October 2009 15:15:09 Timo Sirainen wrote: > > On Thu, 2009-10-01 at 14:59 +0200, Michal Hlavinka wrote: > > > Hi, > > > > > > one Fedora user complains about not some troubles after update to > > > dovecot 1.2. He suspects wrong capability information given by dovecot > > > 1.2 > > > > > > In dovecot.conf he uses imap_capability= option. While response to 'A > > > CAPABILITY' respects imap_capability value, the capability info in > > > hello message does not. > > > > > > for imap_capability=IMAP4 IMAP4rev1 ACL NAMESPACE CHILDREN SORT QUOTA > > > THREAD=ORDEREDSUBJECT UNSELECT IDLE STARTTLS AUTH=PLAIN > > > > I suppose he's using Dovecot as a proxy? Because Dovecot doesn't support > > IMAP4 or THREAD=ORDEREDSUBJECT. > > yes, dovecot is used as proxy > > > > but hello message is: > > > * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE > > > STARTTLS AUTH=PLAIN] Dovecot ready. > > > > Hmm. Yeah.. > > > > > But it seems even when imap_capability is not used capability in hello > > > message is not complete: > > > > .. > > > > > is this expected? Do you think capability information in hello message > > > really can befool clients? > > > > The capability in greeting message is short on purpose. It's only enough > > capabilities to get client logged in. After login Dovecot sends an > > updated full capability list to the client. It uses a few different > > tricks to get most clients understand the change. > > > > So the only potential problem I see here is if client understands the > > greeting capability and permanently remembers that the server supports > > LITERAL+, ID and ENABLE after login but the destination server actually > > doesn't. The other capabilities are relevant only before login. I'm not > > entirely sure what, if anything, I should do about this. would it be possible to: a) send content of imap_capability in greeting message? It should be user's responsibility if it's set to something "weird" b) don't send capability in greeting message if imap_capability is set c) resurrect login_greeting_capability option d) something else? :) > > > > I'd anyway like to hear what exactly is the problem and with what > > client, preferably with IMAP traffic logs showing what's happening > > wrong. > > forwarded info: > The imap-server is dbmail which supports "IMAP4 IMAP4rev1 ACL NAMESPACE > CHILDREN SORT QUOTA THREAD=ORDEREDSUBJECT UNSELECT IDLE" and with dovecot > version 1.1 it worked fine > > The problem sue is "LITERAL+" what dbmail does not support. > The problem client was apple iphone >
Re: [Dovecot] testing needed
On Monday 19 October 2009 23:55:20 Timo Sirainen wrote: > Can someone find an OS where the attached program doesn't work? It > should print "success". So far tested for success: Linux 2.6, Solaris > 10, FreeBSD 7.2, OpenBSD 4.2. > on Fedora 11 (Linux 2.6.30.9 64bit) it failed 3 times (of 200 runs) on Fedora rawhide (Linux 2.6.31.4 64bit) it failed 5 times (of 200 runs)
Re: [Dovecot] Capability info in hello message not complete?
On Tuesday 13 October 2009 19:10:15 Timo Sirainen wrote: > On Tue, 2009-10-13 at 17:26 +0200, Michal Hlavinka wrote: > > would it be possible to: > > a) send content of imap_capability in greeting message? It should be > > user's responsibility if it's set to something "weird" > > I guess I could do this. "could" - does it mean you are waiting for my response? If yes this option is fine for me, since it should fix the issue. /me not native english speaker :) > > b) don't send capability in greeting message if imap_capability is set > > > > c) resurrect login_greeting_capability option > > These have the problem of making Dovecot non-compliant with LEMONADE > extensions. these were just some ideas, it's not required to do all of them to fix iphone imap client.
Re: [Dovecot] Capability info in hello message not complete?
On Tuesday 20 October 2009 21:49:45 Timo Sirainen wrote: > On Tue, 2009-10-20 at 17:10 +0200, Michal Hlavinka wrote: > > On Tuesday 13 October 2009 19:10:15 Timo Sirainen wrote: > > > On Tue, 2009-10-13 at 17:26 +0200, Michal Hlavinka wrote: > > > > would it be possible to: > > > > a) send content of imap_capability in greeting message? It should be > > > > user's responsibility if it's set to something "weird" > > > > > > I guess I could do this. > > > > "could" - does it mean you are waiting for my response? If yes this > > option is fine for me, since it should fix the issue. > > It meant I added it to my TODO list, but hadn't yet got around to doing > it. Anyway, done now: http://hg.dovecot.org/dovecot-1.2/rev/ab32d7e2c0d6 > Reporter has confirmed that iPhone works fine now. thanks
Regression ACL & namespace prefix
Hi
tl;dr:
Seems that for Global ACL directory, namespace prefix is not part of the
path, when looking for acl file.
Long version:
We're planning to update dovecot in next os update to 2.2.36 and while
going through regression testing, we found a problem with ACL
configuration combined with namespace.
Test uses "Global ACL directory" configuration.
Relevant configuration part:
mail_location = maildir:~/Maildir
namespace inbox {
hidden = no
inbox = yes
list = yes
location =
prefix =
separator = /
}
namespace {
hidden = no
list = yes
location = maildir:/var/mail/pub
prefix = pub/
separator = /
type = public
}
mail_plugins = acl
protocol imap {
mail_plugins = $mail_plugins acl imap_acl
}
plugin {
acl = vfile:/etc/dovecot/global-acls
}
ACL config file is stored at:
/etc/dovecot/global-acls/pub/.DEFAULT
when trying to examine "pub", it is denied:
fetchmail: IMAP> A0005 EXAMINE "pub"
fetchmail: IMAP< A0005 NO Mailbox doesn't exist: pub (0.001 + 0.000 secs).
# doveadm acl debug -u d2 pub
doveadm(d2): Info: Mailbox '' is in namespace 'pub/'
doveadm(d2): Info: Mailbox path: /var/mail/pub
doveadm(d2): Info: All message flags are shared across users in mailbox
doveadm(d2): Info: User d2 has no rights for mailbox
doveadm(d2): Error: User d2 is missing 'lookup' right
doveadm(d2): Info: Mailbox pub is NOT visible in LIST
because it did not find acl file:
imap(d2): Debug: Namespace : type=public, prefix=pub/, sep=/, inbox=no,
hidden=no, list=yes, subscriptions=yes location=maildir:/var/mail/pub
imap(d2): Debug: maildir++: root=/var/mail/pub, index=, indexpvt=,
control=, inbox=, alt=
imap(d2): Debug: acl: initializing backend with data:
vfile:/etc/dovecot/global-acls
imap(d2): Debug: acl: acl username = d2
imap(d2): Debug: acl: owner = 0
imap(d2): Debug: acl vfile: Global ACL legacy directory:
/etc/dovecot/global-acls
imap(d2): Debug: pub: Mailbox opened because: EXAMINE
imap(d2): Debug: acl vfile: file /etc/dovecot/global-acls//.DEFAULT not
found
imap(d2): Debug: acl vfile: file /var/mail/pub/dovecot-acl not found
see it's looking for:
/etc/dovecot/global-acls//.DEFAULT
instead of
/etc/dovecot/global-acls/pub/.DEFAULT
Checking with documentation
https://wiki.dovecot.org/ACL
it seems that prefix should still be part of the path, as it was before:
"""The filenames must start with namespace prefix (if it has one). For
example with namespace prefix=INBOX/ containing mailbox "foo" use
/etc/dovecot/acls/INBOX/foo."""
Just for comparison, previous version (2.2.10) would work fine:
imap(d2): Debug: Namespace : type=public, prefix=pub/, sep=/, inbox=no,
hidden=no, list=yes, subscriptions=yes location=maildir:/var/mail/pub
imap(d2): Debug: maildir++: root=/var/mail/pub, index=, indexpvt=,
control=, inbox=, alt=
imap(d2): Debug: acl: initializing backend with data:
vfile:/etc/dovecot/global-acls
imap(d2): Debug: acl: acl username = d2
imap(d2): Debug: acl: owner = 0
imap(d2): Debug: acl vfile: Global ACL directory: /etc/dovecot/global-acls
imap(d2): Debug: acl vfile: reading file
/etc/dovecot/global-acls/pub/.DEFAULT
imap(d2): Debug: acl vfile: file /var/mail/pub/dovecot-acl not found
I've localized problem to:
src/plugins/acl/acl-backend-vfile.c: acl_backend_vfile_object_init(...)
and change from:
vname = mailbox_list_get_vname(_backend->list, name);
to:
vname = *name == '\0' ? "" :
mailbox_list_get_vname(_backend->list, name);
that happened quite time ago during bigger acl changes and I don't know
why exactly this line was changed previously. Anyway, reverting this
line alone fixes the problem and while testing both per-mailbox ACL
vfile and Global ACL file, reverting this did not affect them.
Re: Dovecot v2.3.13 released
On 04. 01. 21 13:02, Aki Tuomi wrote:
We are pleased to release v2.3.13. Please find it from locations below:
https://dovecot.org/releases/2.3/dovecot-2.3.13.tar.gz
https://dovecot.org/releases/2.3/dovecot-2.3.13.tar.gz.sig
Binary packages in https://repo.dovecot.org/
Docker images in https://hub.docker.com/r/dovecot/dovecot
Hi,
for i686 and armv7hl build time test fails on
Panic: file time-util.c: line 65 (timeval_cmp_margin): assertion failed:
(usecs_diff >= 0)
On these architectures, time_t in timeval->tv_sec is only 4 bytes, same
as (long) int.
This causes test to fail in
test_timeval_cmp_margin for test data
...
},{
.tv1 = { -INT_MAX, 0 },
.tv2 = { INT_MAX, 0 },
.output = -1,
},
...
as timeval_cmp_margin(...) tries to substract negative value from
maximal value and it overflows
48: usecs_diff = (tv2->tv_sec - tv1->tv_sec) * 100LL +
49: (tv2->tv_usec - tv1->tv_usec);
Cheers,
Michal
Re: 2.3.13: newly introduced TLS bug : tls_construct_server_key_exchange
Hard to say without reproducer and more information, but I think it was a downstream bug. There was configuration error in 2.3.13-1 build. I'm not sure how exactly it could cause this error, but I did not see any report for the new build so far. On 07. 01. 21 17:31, Marius Schwarz wrote: Hi, since the update from 2.3.11 to 2.3.13 some clients generate this bug : TLS handshaking: SSL_accept() failed: error:141EC044:SSL routines:tls_construct_server_key_exchange:internal error As it looks for now, they use the old SSL approach on Ports 993 and 995. SSL Config says: ssl = yes ssl_cert =
doveadm purge -A includes users with gid outside of limits and then reports error
Hi,
one our user reported that when he runs "doveadm purge -A" it goes
through users that don't have gid in the first_valid_gid-last_valid_git
range and it reports error. For example:
doveadm(dovenull): Error: user dovenull: Mail access for users with GID
996 not permitted (see first_valid_gid in config file, gid from userdb
lookup).
doveadm(dovenull): Error: User init failed
auth/userdb-passwd.c : passwd_iterate_want_pw(...) has checks for UID
range, but does not have checks for GID range. Is there any reason for
this? We've added those checks (see attached patch) and all seems fine.
Cheers,
Michal Hlavinka
diff -up dovecot-2.2.24/src/auth/auth-settings.c.gidlimit dovecot-2.2.24/src/auth/auth-settings.c
--- dovecot-2.2.24/src/auth/auth-settings.c.gidlimit 2016-04-26 15:01:20.0 +0200
+++ dovecot-2.2.24/src/auth/auth-settings.c 2016-06-27 16:57:44.112990614 +0200
@@ -254,6 +254,8 @@ static const struct setting_define auth_
DEF_NOPREFIX(SET_BOOL, verbose_proctitle),
DEF_NOPREFIX(SET_UINT, first_valid_uid),
DEF_NOPREFIX(SET_UINT, last_valid_uid),
+ DEF_NOPREFIX(SET_UINT, first_valid_gid),
+ DEF_NOPREFIX(SET_UINT, last_valid_gid),
SETTING_DEFINE_LIST_END
};
@@ -294,6 +296,8 @@ static const struct auth_settings auth_d
.verbose_proctitle = FALSE,
.first_valid_uid = 500,
.last_valid_uid = 0,
+ .first_valid_gid = 1,
+ .last_valid_gid = 0,
};
const struct setting_parser_info auth_setting_parser_info = {
diff -up dovecot-2.2.24/src/auth/auth-settings.h.gidlimit dovecot-2.2.24/src/auth/auth-settings.h
--- dovecot-2.2.24/src/auth/auth-settings.h.gidlimit 2016-04-26 15:01:20.0 +0200
+++ dovecot-2.2.24/src/auth/auth-settings.h 2016-06-27 16:57:44.113990616 +0200
@@ -70,6 +70,8 @@ struct auth_settings {
bool verbose_proctitle;
unsigned int first_valid_uid;
unsigned int last_valid_uid;
+ unsigned int first_valid_gid;
+ unsigned int last_valid_gid;
/* generated: */
char username_chars_map[256];
diff -up dovecot-2.2.24/src/auth/userdb-passwd.c.gidlimit dovecot-2.2.24/src/auth/userdb-passwd.c
--- dovecot-2.2.24/src/auth/userdb-passwd.c.gidlimit 2016-04-26 15:01:20.0 +0200
+++ dovecot-2.2.24/src/auth/userdb-passwd.c 2016-06-27 16:57:44.113990616 +0200
@@ -145,6 +145,10 @@ passwd_iterate_want_pw(struct passwd *pw
return FALSE;
if (pw->pw_uid > (uid_t)set->last_valid_uid && set->last_valid_uid != 0)
return FALSE;
+ if (pw->pw_gid < (gid_t)set->first_valid_gid)
+ return FALSE;
+ if (pw->pw_gid > (gid_t)set->last_valid_gid && set->last_valid_gid != 0)
+ return FALSE;
return TRUE;
}
dovecot & cap_net_admin capability
Hi, we've seen SELinux reports from our users that dovecot tried to use something that needs CAP_NET_ADMIN capability. Before enabling it, we would like to know where it originated from. I've checked the sources, but was not able to find anything that would require this capability. Do you know for what it is used? CAP_NET_ADMIN Perform various network-related operations: * interface configuration; * administration of IP firewall, masquerading, and accounting; * modify routing tables; * bind to any address for transparent proxying "IP_TRANSPARENT"; * set type-of-service (TOS) "IP_TOS" * clear driver statistics; * set promiscuous mode; * enabling multicasting; * use setsockopt(2) to set the following socket options: SO_DEBUG, SO_MARK, SO_PRIORITY (for a priority outside the range 0 to 6),SO_RCVBUFFORCE, and SO_SNDBUFFORCE Cheers, Michal Hlavinka
Re: dovecot & cap_net_admin capability
we've seen SELinux reports from our users that dovecot tried to use something that needs CAP_NET_ADMIN capability. Before enabling it, we would like to know where it originated from. I've checked the sources, but was not able to find anything that would require this capability. Do you know for what it is used? Is this something that changed recently? Anyway, no idea. Do they have any more details, like is it even the dovecot master process that causes it? Or does it say which syscall fails? Thanks for the answer. We've looked into this a little bit more and found out that this message is caused by what happens in kernel (and network configuration). It is not caused by what dovecot does. Cheers, Michal
dovecot 2.4 issue with openssl >= 3.0.8
Hi,
I've started testing main git branch and found an issue with openssl 3.
Test suite fails:
test_load_v1_key ... : ok
test-crypto.c:445: Assert failed: ret == TRUE
test-crypto.c:446: Assert failed: error == NULL
Panic: file dcrypt-openssl3.c: line 2917
(dcrypt_openssl_public_key_type): assertion failed: (key != NULL &&
key->key != NULL)
Error: Raw backtrace: test-crypto(+0x5af01) [0x55951b667f01] ->
test-crypto(backtrace_get+0x2f) [0x55951b66877f] ->
test-crypto(+0x31291) [0x55951b63e291] -> test-crypto(+0x312d5)
[0x55951b63e2d5] -> test-crypto(+0x16025) [0x55951b623025] ->
libdcrypt_openssl.so(+0x70ff) [0x7f5a995b60ff] -> test-crypto(+0x2a17b)
[0x55951b63717b] -> test-crypto(+0x3055d) [0x55951b63d55d] ->
test-crypto(test_run+0x6c) [0x55951b63d61c] -> test-crypto(main+0x4e)
[0x55951b62b66e] -> libc.so.6(+0x27b4a) [0x7f5a995eeb4a] ->
libc.so.6(__libc_start_main+0x8b) [0x7f5a995eec0b] ->
test-crypto(_start+0x25) [0x55951b62b7e5]
The issue is caused by change in openssl >= 3.0.8
in lib-dcryt/dcrypt-openssl3.c method ec_key_get_pub_point_hex(...)
in old version (for openssl 1.x) it uses compressed format:
EC_POINT_point2hex(g, p, POINT_CONVERSION_COMPRESSED, NULL);
in openssl3 version it uses
EVP_PKEY_get_octet_string_param(pkey, OSSL_PKEY_PARAM_PUB_KEY, buf,
sizeof(buf), &len);
but key is created in dcrypt_evp_pkey_from_point(...)
with OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT, "uncompressed"
this was working in openssl pre 3.0.8 as compression format was ignored
when dumping data and used always compressed format.
From https://www.openssl.org/docs/man3.0/man7/EVP_KEYMGMT-EC.html
""" Before OpenSSL 3.0.8, the implementation of providers included with
OpenSSL always opted for an encoding in compressed format,
unconditionally. Since OpenSSL 3.0.8, the implementation has been
changed to honor the OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT
parameter, if set, or to default to uncompressed format."""
I don't see simple way how to force compressed format just for dumping
data without effecting the key itself. Method that can be used with
compression format argument is EC_POINT_point2hex but it requires quite
lengthy extraction of EC_POINT first. I've tried this for testing with:
static const char *ec_key_get_pub_point_hex(const EVP_PKEY *pkey)
{
if (!EVP_PKEY_is_a(pkey, "EC"))
return NULL;
size_t len;
EVP_PKEY_get_utf8_string_param(pkey, OSSL_PKEY_PARAM_GROUP_NAME, NULL,
0, &len);
buffer_t *parambuf = t_buffer_create(len+1);
EVP_PKEY_get_utf8_string_param(pkey, OSSL_PKEY_PARAM_GROUP_NAME, (char
*)parambuf->data, len+1, &len);
int nid = OBJ_txt2nid(parambuf->data);
EVP_PKEY_get_octet_string_param(pkey, OSSL_PKEY_PARAM_PUB_KEY, NULL, 0,
&len);
parambuf = t_buffer_create(len+1);
EVP_PKEY_get_octet_string_param(pkey, OSSL_PKEY_PARAM_PUB_KEY,
(unsigned char *)parambuf->data, len+1, &len);
EC_GROUP *ec_grp = EC_GROUP_new_by_curve_name(nid);
if (ec_grp == NULL)
return NULL;
EC_POINT *point = EC_POINT_new(ec_grp);
if (point == NULL) {
EC_GROUP_free(ec_grp);
return NULL;
}
if (!EC_POINT_oct2point(ec_grp, point, parambuf->data, len, NULL))
return NULL;
char *ret = EC_POINT_point2hex(ec_grp, point,
POINT_CONVERSION_COMPRESSED, NULL);
EC_GROUP_free(ec_grp);
EC_POINT_free(point);
return ret;
}
and it fixed the issue, but there may be an easier way how to achieve that.
Cheers
Michal Hlavinka
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
Re: dovecot 2.4 issue with openssl >= 3.0.8
Hi,
this patch does not fix the issue. It fixes that first test that failed,
but it fails a little bit further:
"""
test_read_increment .. : ok
test-stream.c:241: Assert failed: is_2->stream_errno == 0
test_write_read_v1 ... :
FAILED
test-stream.c:294: Assert failed: is_2->stream_errno == 0
test_write_read_v1_short . :
FAILED
"""
previously compression format was forced only for hex dump, this patch
affects how some keys are created, but does not affect those that are
loaded directly for example through PEM_read_bio_PUBKEY in:
dcrypt-openssl3.c:
dcrypt_openssl_load_public_key:2460:PEM_read_bio_PUBKEY
Cheers,
Michal Hlavinka
On 21/08/2023 09:08, Aki Tuomi wrote:
I think this should fix it https://cmouse.fi/ec-point.patch, can you please
give it a try?
Aki
On 21/08/2023 09:34 EEST Aki Tuomi wrote:
On 16/08/2023 01:09 EEST Michal Hlavinka wrote:
Hi,
I've started testing main git branch and found an issue with openssl 3.
Test suite fails:
test_load_v1_key ... : ok
test-crypto.c:445: Assert failed: ret == TRUE
test-crypto.c:446: Assert failed: error == NULL
Panic: file dcrypt-openssl3.c: line 2917
(dcrypt_openssl_public_key_type): assertion failed: (key != NULL &&
key->key != NULL)
Error: Raw backtrace: test-crypto(+0x5af01) [0x55951b667f01] ->
test-crypto(backtrace_get+0x2f) [0x55951b66877f] ->
test-crypto(+0x31291) [0x55951b63e291] -> test-crypto(+0x312d5)
[0x55951b63e2d5] -> test-crypto(+0x16025) [0x55951b623025] ->
libdcrypt_openssl.so(+0x70ff) [0x7f5a995b60ff] -> test-crypto(+0x2a17b)
[0x55951b63717b] -> test-crypto(+0x3055d) [0x55951b63d55d] ->
test-crypto(test_run+0x6c) [0x55951b63d61c] -> test-crypto(main+0x4e)
[0x55951b62b66e] -> libc.so.6(+0x27b4a) [0x7f5a995eeb4a] ->
libc.so.6(__libc_start_main+0x8b) [0x7f5a995eec0b] ->
test-crypto(_start+0x25) [0x55951b62b7e5]
The issue is caused by change in openssl >= 3.0.8
in lib-dcryt/dcrypt-openssl3.c method ec_key_get_pub_point_hex(...)
in old version (for openssl 1.x) it uses compressed format:
EC_POINT_point2hex(g, p, POINT_CONVERSION_COMPRESSED, NULL);
in openssl3 version it uses
EVP_PKEY_get_octet_string_param(pkey, OSSL_PKEY_PARAM_PUB_KEY, buf,
sizeof(buf), &len);
but key is created in dcrypt_evp_pkey_from_point(...)
with OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT, "uncompressed"
this was working in openssl pre 3.0.8 as compression format was ignored
when dumping data and used always compressed format.
From https://www.openssl.org/docs/man3.0/man7/EVP_KEYMGMT-EC.html
""" Before OpenSSL 3.0.8, the implementation of providers included with
OpenSSL always opted for an encoding in compressed format,
unconditionally. Since OpenSSL 3.0.8, the implementation has been
changed to honor the OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT
parameter, if set, or to default to uncompressed format."""
I don't see simple way how to force compressed format just for dumping
data without effecting the key itself. Method that can be used with
compression format argument is EC_POINT_point2hex but it requires quite
lengthy extraction of EC_POINT first. I've tried this for testing with:
static const char *ec_key_get_pub_point_hex(const EVP_PKEY *pkey)
{
if (!EVP_PKEY_is_a(pkey, "EC"))
return NULL;
size_t len;
EVP_PKEY_get_utf8_string_param(pkey, OSSL_PKEY_PARAM_GROUP_NAME, NULL,
0, &len);
buffer_t *parambuf = t_buffer_create(len+1);
EVP_PKEY_get_utf8_string_param(pkey, OSSL_PKEY_PARAM_GROUP_NAME, (char
*)parambuf->data, len+1, &len);
int nid = OBJ_txt2nid(parambuf->data);
EVP_PKEY_get_octet_string_param(pkey, OSSL_PKEY_PARAM_PUB_KEY, NULL, 0,
&len);
parambuf = t_buffer_create(len+1);
EVP_PKEY_get_octet_string_param(pkey, OSSL_PKEY_PARAM_PUB_KEY,
(unsigned char *)parambuf->data, len+1, &len);
EC_GROUP *ec_grp = EC_GROUP_new_by_curve_name(nid);
if (ec_grp == NULL)
return NULL;
EC_POINT *point = EC_POINT_new(ec_grp);
if (point == NULL) {
EC_GROUP_free(ec_grp);
return NULL;
}
if (!EC_POINT_oct2point(ec_grp, point, parambuf->data, len, NULL))
return NULL;
char *ret = EC_POINT_point2hex(ec_grp, point,
POINT_CONVERSION_COMPRESSED, NULL);
EC_GROUP_free(ec_grp);
EC_POINT_free(point);
return ret;
}
and it fixed the issue, but there may be an easier way how to achieve that.
Cheers
Michal Hlavinka
Thank you for reporting this, we'll take a look at it!
Aki
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
Re: dovecot 2.4 issue with openssl >= 3.0.8
updated patch works
On 21/08/2023 22:29, Aki Tuomi wrote:
Hi!
Thanks for pointing this out, I've updated the patch, and made it bit
differently to ensure it works regardless where the key came from.
Aki
On 21/08/2023 23:04 EEST Michal Hlavinka wrote:
Hi,
this patch does not fix the issue. It fixes that first test that failed,
but it fails a little bit further:
"""
test_read_increment .. : ok
test-stream.c:241: Assert failed: is_2->stream_errno == 0
test_write_read_v1 ... :
FAILED
test-stream.c:294: Assert failed: is_2->stream_errno == 0
test_write_read_v1_short . :
FAILED
"""
previously compression format was forced only for hex dump, this patch
affects how some keys are created, but does not affect those that are
loaded directly for example through PEM_read_bio_PUBKEY in:
dcrypt-openssl3.c:
dcrypt_openssl_load_public_key:2460:PEM_read_bio_PUBKEY
Cheers,
Michal Hlavinka
On 21/08/2023 09:08, Aki Tuomi wrote:
I think this should fix it https://cmouse.fi/ec-point.patch, can you please
give it a try?
Aki
On 21/08/2023 09:34 EEST Aki Tuomi wrote:
On 16/08/2023 01:09 EEST Michal Hlavinka wrote:
Hi,
I've started testing main git branch and found an issue with openssl 3.
Test suite fails:
test_load_v1_key ... : ok
test-crypto.c:445: Assert failed: ret == TRUE
test-crypto.c:446: Assert failed: error == NULL
Panic: file dcrypt-openssl3.c: line 2917
(dcrypt_openssl_public_key_type): assertion failed: (key != NULL &&
key->key != NULL)
Error: Raw backtrace: test-crypto(+0x5af01) [0x55951b667f01] ->
test-crypto(backtrace_get+0x2f) [0x55951b66877f] ->
test-crypto(+0x31291) [0x55951b63e291] -> test-crypto(+0x312d5)
[0x55951b63e2d5] -> test-crypto(+0x16025) [0x55951b623025] ->
libdcrypt_openssl.so(+0x70ff) [0x7f5a995b60ff] -> test-crypto(+0x2a17b)
[0x55951b63717b] -> test-crypto(+0x3055d) [0x55951b63d55d] ->
test-crypto(test_run+0x6c) [0x55951b63d61c] -> test-crypto(main+0x4e)
[0x55951b62b66e] -> libc.so.6(+0x27b4a) [0x7f5a995eeb4a] ->
libc.so.6(__libc_start_main+0x8b) [0x7f5a995eec0b] ->
test-crypto(_start+0x25) [0x55951b62b7e5]
The issue is caused by change in openssl >= 3.0.8
in lib-dcryt/dcrypt-openssl3.c method ec_key_get_pub_point_hex(...)
in old version (for openssl 1.x) it uses compressed format:
EC_POINT_point2hex(g, p, POINT_CONVERSION_COMPRESSED, NULL);
in openssl3 version it uses
EVP_PKEY_get_octet_string_param(pkey, OSSL_PKEY_PARAM_PUB_KEY, buf,
sizeof(buf), &len);
but key is created in dcrypt_evp_pkey_from_point(...)
with OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT, "uncompressed"
this was working in openssl pre 3.0.8 as compression format was ignored
when dumping data and used always compressed format.
From https://www.openssl.org/docs/man3.0/man7/EVP_KEYMGMT-EC.html
""" Before OpenSSL 3.0.8, the implementation of providers included with
OpenSSL always opted for an encoding in compressed format,
unconditionally. Since OpenSSL 3.0.8, the implementation has been
changed to honor the OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT
parameter, if set, or to default to uncompressed format."""
I don't see simple way how to force compressed format just for dumping
data without effecting the key itself. Method that can be used with
compression format argument is EC_POINT_point2hex but it requires quite
lengthy extraction of EC_POINT first. I've tried this for testing with:
static const char *ec_key_get_pub_point_hex(const EVP_PKEY *pkey)
{
if (!EVP_PKEY_is_a(pkey, "EC"))
return NULL;
size_t len;
EVP_PKEY_get_utf8_string_param(pkey, OSSL_PKEY_PARAM_GROUP_NAME, NULL,
0, &len);
buffer_t *parambuf = t_buffer_create(len+1);
EVP_PKEY_get_utf8_string_param(pkey, OSSL_PKEY_PARAM_GROUP_NAME, (char
*)parambuf->data, len+1, &len);
int nid = OBJ_txt2nid(parambuf->data);
EVP_PKEY_get_octet_string_param(pkey, OSSL_PKEY_PARAM_PUB_KEY, NULL, 0,
&len);
parambuf = t_buffer_create(len+1);
EVP_PKEY_get_octet_string_param(pkey, OSSL_PKEY_PARAM_PUB_KEY,
(unsigned char *)parambuf->data, len+1, &len);
EC_GROUP *ec_grp = EC_GROUP_new_by_curve_name(nid);
if (ec_grp == NULL)
return NULL;
EC_POINT *point = EC_POINT_new(ec_grp);
if (point == NULL) {
EC_GROUP_free(ec_grp);
return NULL;
}
if (!EC_POINT_oct2point(ec_grp, point, parambuf->data, len, NULL))
return NULL;
char *ret = EC_POINT_point2hex(ec_grp, point,
POINT_CONVERSION_COMPRESSED, NULL);
EC_GROUP_free(ec_grp);
EC_POINT_free(point)
Re: v2.2.17 released
On 05/13/2015 08:36 PM, Timo Sirainen wrote: http://dovecot.org/releases/2.2/dovecot-2.2.17.tar.gz http://dovecot.org/releases/2.2/dovecot-2.2.17.tar.gz.sig A few director improvements since RC2, some fixes and a new plugin: http://wiki2.dovecot.org/Plugins/QuotaClone Hi, there seems to be some fts problem, as 2.2.17 crashes during the test check: fts filter find .. : ok fts filter lowercase . : ok fts filter stopwords, English : ok fts filter stopwords, Finnish : ok fts filter stopwords, French . : ok fts filter stopwords, fail filter() (lazy init) .. : ok fts filter normalizer Swedish short text . : ok fts filter normalizer Swedish short text using default ID : ok fts filter normalizer French UDHR : ok fts filter normalizer empty tokens ... : ok fts filter normalizer invalid id . : ok test-fts-filter.c:512: Assert failed: fts_filter_create(fts_filter_stemmer_snowball, filter, &english_language, NULL, &stemmer, &error) == 0 ../../run-test.sh: line 11: 18401 Segmentation fault (core dumped) valgrind -q --log-file=test.out.$$ $* ==18401== Invalid read of size 8 ==18401==at 0x10DDA2: fts_filter_filter (fts-filter.c:101) ==18401==by 0x10BF0E: test_fts_filter_normalizer_stopwords_stemmer_eng (test-fts-filter.c:517) ==18401==by 0x10ECAD: test_run_funcs (test-common.c:311) ==18401==by 0x10F390: test_run (test-common.c:361) ==18401==by 0x10B931: main (test-fts-filter.c:567) ==18401== Address 0x18 is not stack'd, malloc'd or (recently) free'd ==18401== ==18401== ==18401== Process terminating with default action of signal 11 (SIGSEGV) ==18401== Access not within mapped region at address 0x18 ==18401==at 0x10DDA2: fts_filter_filter (fts-filter.c:101) ==18401==by 0x10BF0E: test_fts_filter_normalizer_stopwords_stemmer_eng (test-fts-filter.c:517) ==18401==by 0x10ECAD: test_run_funcs (test-common.c:311) ==18401==by 0x10F390: test_run (test-common.c:361) ==18401==by 0x10B931: main (test-fts-filter.c:567) ==18401== If you believe this happened as a result of a stack ==18401== overflow in your program's main thread (unlikely but ==18401== possible), you can try to increase the size of the ==18401== main thread stack using the --main-stacksize= flag. ==18401== The main thread stack size used in this run was 8388608. Makefile:840: recipe for target 'check-test' failed make[2]: *** [check-test] Error 1
Assert test not compatible with s390(x) and ppc64 architectures
Hi,
we have found that assert test fails on some architectures:
test-net.c:59: Assert failed: net_addr2ip("127.0.0.1", &ip) == 0 &&
ip.family == AF_INET && ip.u.ip4.s_addr == (127 | (1 << 24))
It seems as bug in test suit as test is expecting IPv4 address in LE
format (0x017f), but it gets address in BE format(0x7f01). Patch
in attachment should fix this issue.
Regards
Michal Hlavinka
--- dovecot-2.2.18/src/lib/test-net.c 2015-05-03 05:12:11.0 -0400
+++ dovecot-2.2.18/src/lib/test-net.c 2015-06-17 03:18:02.571420401 -0400
@@ -56,7 +56,7 @@ static void test_net_ip2addr(void)
test_begin("net_ip2addr()");
test_assert(net_addr2ip("127.0.0.1", &ip) == 0 &&
ip.family == AF_INET &&
- ip.u.ip4.s_addr == (127 | (1 << 24)));
+ ntohl(ip.u.ip4.s_addr) == (0x7f01));
#ifdef HAVE_IPV6
test_assert(net_addr2ip("::5", &ip) == 0 &&
ip.family == AF_INET6 &&
[Dovecot] [bug] ssl-params hangs when FIPS is enabled
Hi,
we found a bug in ssl-params. It calls openssl DH generator for 512 and
1024 bits, but in FIPS mode, openssl won't generate anything for less
than 1024, so it fails with:
error:0506A06E:Diffie-Hellman routines:DH_BUILTIN_GENPARAMS:key size too
small
but when DH generator fails, ssl-params hangs forever in io_loop_run:
__epoll_wait_nocancel()
io_loop_handler_run(..) at ioloop-epoll.c:176
io_loop_run(..) at ioloop.c:406
master_service_run(..) at master-service.c:566
main(..) at main.c:156
Getting system in FIPS mode can be a little tricky, but DH_generator
simulated failure can do the trick. Just change
ssl-params/ssl-params-openssl.c:generate_dh_paramaters:39
- if (dh == NULL) {
+ if (1 || dh == NULL) {
and when you run ssl-params (with no ssl-parameters.dat), it hangs.
Let me know if you need more information.
Regards,
Michal Hlavinka
Re: [Dovecot] [bug] ssl-params hangs when FIPS is enabled
On 11/02/2013 02:31 PM, Timo Sirainen wrote: On 1.10.2013, at 21.14, Michal Hlavinka wrote: we found a bug in ssl-params. It calls openssl DH generator for 512 and 1024 bits, but in FIPS mode, openssl won't generate anything for less than 1024, so it fails with: error:0506A06E:Diffie-Hellman routines:DH_BUILTIN_GENPARAMS:key size too small but when DH generator fails, ssl-params hangs forever in io_loop_run: http://hg.dovecot.org/dovecot-2.2/rev/c472e0454ee3 should fix this. tested (whole 2.2.7) and it works fine Thanks
Re: [Dovecot] [bug] ssl-params hangs when FIPS is enabled
On 11/02/2013 02:31 PM, Timo Sirainen wrote: On 1.10.2013, at 21.14, Michal Hlavinka wrote: we found a bug in ssl-params. It calls openssl DH generator for 512 and 1024 bits, but in FIPS mode, openssl won't generate anything for less than 1024, so it fails with: error:0506A06E:Diffie-Hellman routines:DH_BUILTIN_GENPARAMS:key size too small but when DH generator fails, ssl-params hangs forever in io_loop_run: http://hg.dovecot.org/dovecot-2.2/rev/c472e0454ee3 should fix this. I spoke too soon. Original issue is fixed - when FIPS mode is enabled, ssl-params no longer fails. On the other hand, underlaying problem still exists. When ssl-params fails (for whatever reason) it gets stuck. One way to reproduce it is chroot without /dev populated # /usr/libexec/dovecot/ssl-params Info: Generating SSL parameters Fatal: DH_generate_parameters(bits=1024, gen=2) failed: error:24064064:lib(36):func(100):reason(100) Error: child process failed with status 22784 -> ssl-params is stuck
Re: Regression ACL & namespace prefix
Hi,
any progress with this issue? Do you need more information to debug and
fix this?
Cheers
Michal Hlavinka
On 9/18/18 4:10 PM, Michal Hlavinka wrote:
Hi
tl;dr:
Seems that for Global ACL directory, namespace prefix is not part of the
path, when looking for acl file.
Long version:
We're planning to update dovecot in next os update to 2.2.36 and while
going through regression testing, we found a problem with ACL
configuration combined with namespace.
Test uses "Global ACL directory" configuration.
Relevant configuration part:
mail_location = maildir:~/Maildir
namespace inbox {
hidden = no
inbox = yes
list = yes
location =
prefix =
separator = /
}
namespace {
hidden = no
list = yes
location = maildir:/var/mail/pub
prefix = pub/
separator = /
type = public
}
mail_plugins = acl
protocol imap {
mail_plugins = $mail_plugins acl imap_acl
}
plugin {
acl = vfile:/etc/dovecot/global-acls
}
ACL config file is stored at:
/etc/dovecot/global-acls/pub/.DEFAULT
when trying to examine "pub", it is denied:
fetchmail: IMAP> A0005 EXAMINE "pub"
fetchmail: IMAP< A0005 NO Mailbox doesn't exist: pub (0.001 + 0.000 secs).
# doveadm acl debug -u d2 pub
doveadm(d2): Info: Mailbox '' is in namespace 'pub/'
doveadm(d2): Info: Mailbox path: /var/mail/pub
doveadm(d2): Info: All message flags are shared across users in mailbox
doveadm(d2): Info: User d2 has no rights for mailbox
doveadm(d2): Error: User d2 is missing 'lookup' right
doveadm(d2): Info: Mailbox pub is NOT visible in LIST
because it did not find acl file:
imap(d2): Debug: Namespace : type=public, prefix=pub/, sep=/, inbox=no,
hidden=no, list=yes, subscriptions=yes location=maildir:/var/mail/pub
imap(d2): Debug: maildir++: root=/var/mail/pub, index=, indexpvt=,
control=, inbox=, alt=
imap(d2): Debug: acl: initializing backend with data:
vfile:/etc/dovecot/global-acls
imap(d2): Debug: acl: acl username = d2
imap(d2): Debug: acl: owner = 0
imap(d2): Debug: acl vfile: Global ACL legacy directory:
/etc/dovecot/global-acls
imap(d2): Debug: pub: Mailbox opened because: EXAMINE
imap(d2): Debug: acl vfile: file /etc/dovecot/global-acls//.DEFAULT not
found
imap(d2): Debug: acl vfile: file /var/mail/pub/dovecot-acl not found
see it's looking for:
/etc/dovecot/global-acls//.DEFAULT
instead of
/etc/dovecot/global-acls/pub/.DEFAULT
Checking with documentation
https://wiki.dovecot.org/ACL
it seems that prefix should still be part of the path, as it was before:
"""The filenames must start with namespace prefix (if it has one). For
example with namespace prefix=INBOX/ containing mailbox "foo" use
/etc/dovecot/acls/INBOX/foo."""
Just for comparison, previous version (2.2.10) would work fine:
imap(d2): Debug: Namespace : type=public, prefix=pub/, sep=/, inbox=no,
hidden=no, list=yes, subscriptions=yes location=maildir:/var/mail/pub
imap(d2): Debug: maildir++: root=/var/mail/pub, index=, indexpvt=,
control=, inbox=, alt=
imap(d2): Debug: acl: initializing backend with data:
vfile:/etc/dovecot/global-acls
imap(d2): Debug: acl: acl username = d2
imap(d2): Debug: acl: owner = 0
imap(d2): Debug: acl vfile: Global ACL directory: /etc/dovecot/global-acls
imap(d2): Debug: acl vfile: reading file
/etc/dovecot/global-acls/pub/.DEFAULT
imap(d2): Debug: acl vfile: file /var/mail/pub/dovecot-acl not found
I've localized problem to:
src/plugins/acl/acl-backend-vfile.c: acl_backend_vfile_object_init(...)
and change from:
vname = mailbox_list_get_vname(_backend->list, name);
to:
vname = *name == '\0' ? "" :
mailbox_list_get_vname(_backend->list, name);
that happened quite time ago during bigger acl changes and I don't know
why exactly this line was changed previously. Anyway, reverting this
line alone fixes the problem and while testing both per-mailbox ACL
vfile and Global ACL file, reverting this did not affect them.
Re: Regression ACL & namespace prefix
Hi,
thanks for the answer. I think your environment was not set up correctly
to reproduce this bug. I've retested with 2.3.5 and I can still
reproduce it. I've attached a script that will configure everything for
testing and if you have a virtual machine available, you can use it
directly (it expects linux with systemd for dovecot restart).
relevant section from config:
namespace {
hidden = no
list = yes
location = maildir:/var/mail/pub
prefix = pub/
separator = /
type = public
}
this expects maildir directly in pub:
/var/mail/pub/cur
/var/mail/pub/new
/var/mail/pub/tmp
as it uses '/' separator and there could be subfolders, it should look
for .DEFAULT file in global acls directory which it does not in your
debug output
doveadm(testuser): Info: Mailbox '' is in namespace 'pub/'
doveadm(testuser): Info: All message flags are shared across users in
mailbox
doveadm(testuser): Debug: acl vfile: file /etc/dovecot/global-acls//.DEFAULT
not found
doveadm(testuser): Debug: acl vfile: file /var/mail/pub/dovecot-acl not
found
doveadm(testuser): Info: User testuser has no rights for mailbox
doveadm(testuser): Error: User testuser is missing 'lookup' right
doveadm(testuser): Info: Mailbox pub is NOT visible in LIST
in this output see that it checks this location:
acl vfile: file /etc/dovecot/global-acls//.DEFAULT not found
instead of
/etc/dovecot/global-acls/pub/.DEFAULT
this is caused by line in
src/plugins/acl/acl-backend-vfile.c: acl_backend_vfile_object_init(...)
vname = *name == '\0' ? "" :
mailbox_list_get_vname(_backend->list, name);
and because name is empty, it will not use the "pub" prefix in the path.
If I'd test acl for "pub/subfolder" that condition would have different
result and bug would not trigger:
doveadm(testuser): Debug: acl vfile: reading file
/etc/dovecot/global-acls/pub/subfolder/.DEFAULT
For testing I use this acl configuration:
cat /etc/dovecot/global-acls/pub/.DEFAULT
user=testuser l
but as this acl file location is not found by dovecot, content should
not matter.
Cheers,
Michal Hlavinka
On 3/7/19 7:00 PM, Aki Tuomi via dovecot wrote:
I tested with release 2.3.5, and
doveadm -Dv acl debug -u testuser pub doveadm(testuser): Debug: acl
vfile: file /etc/dovecot/global-acls/pub/INBOX not found
doveadm(testuser): Debug: acl vfile: file
/home/vmail/pub/Mail/mailboxes/INBOX/dbox-Mails/dovecot-acl not
found doveadm(testuser): Debug: acl vfile: file
/etc/dovecot/global-acls/ not found doveadm(testuser): Debug: acl
vfile: file /home/vmail/pub/Mail/mailboxes/dovecot-acl not found
so our advice is to upgrade into 2.3.5, as 2.2.36 is no longer in
development.
Aki
On 7 March 2019 19:47 Aki Tuomi via dovecot
wrote:
Sorry, we have not yet been able to look into this..
It's now in our internal system as DOP-966
Aki
On 7 March 2019 17:31 Michal Hlavinka via dovecot
wrote:
Hi, any progress with this issue? Do you need more information to
debug and fix this?
Cheers Michal Hlavinka
On 9/18/18 4:10 PM, Michal Hlavinka wrote:
Hi
tl;dr: Seems that for Global ACL directory, namespace prefix is
not part of the path, when looking for acl file.
Long version:
We're planning to update dovecot in next os update to 2.2.36
and while going through regression testing, we found a problem
with ACL configuration combined with namespace.
Test uses "Global ACL directory" configuration.
Relevant configuration part: mail_location = maildir:~/Maildir
namespace inbox { hidden = no inbox = yes list = yes location
= prefix = separator = / } namespace { hidden = no list = yes
location = maildir:/var/mail/pub prefix = pub/ separator = /
type = public }
mail_plugins = acl
protocol imap { mail_plugins = $mail_plugins acl imap_acl }
plugin { acl = vfile:/etc/dovecot/global-acls }
ACL config file is stored at:
/etc/dovecot/global-acls/pub/.DEFAULT
when trying to examine "pub", it is denied: fetchmail: IMAP>
A0005 EXAMINE "pub" fetchmail: IMAP< A0005 NO Mailbox doesn't
exist: pub (0.001 + 0.000 secs).
# doveadm acl debug -u d2 pub doveadm(d2): Info: Mailbox '' is
in namespace 'pub/' doveadm(d2): Info: Mailbox path:
/var/mail/pub doveadm(d2): Info: All message flags are shared
across users in mailbox doveadm(d2): Info: User d2 has no
rights for mailbox doveadm(d2): Error: User d2 is missing
'lookup' right doveadm(d2): Info: Mailbox pub is NOT visible in
LIST
because it did not find acl file: imap(d2): Debug: Namespace :
type=public, prefix=pub/, sep=/, inbox=no, hidden=no, list=yes,
subscriptions=yes location=maildir:/var/mail/pub imap(d2):
Debug: maildir++: root=/var/mail/pub, index=, indexpvt=,
control=, inbox=, alt= imap(d2): Debug: acl: initializing
backend with data: vfile:/etc/dovecot/global-acls imap(d2):
Debug: acl: acl username = d2 imap(d2): Debug: acl: owner = 0
imap(d2): D
Re: Regression ACL & namespace prefix
On 3/12/19 10:18 PM, Timo Sirainen via dovecot wrote: On 18 Sep 2018, at 17.10, Michal Hlavinka <mailto:mhlav...@redhat.com>> wrote: Seems that for Global ACL directory, namespace prefix is not part of the path, when looking for acl file. Is there a reason you're using ACL directory instead of ACL file? I've rather been thinking about removing code for ACL directories entirely at some point. The main reason is "if it works, don't touch it". Which includes zero admin time required, no downtime required and benefit of long time verified configuration. We did some tests before updating dovecot in distribution, as users like to deploy and forget, as any attention required (whatever reason) is disruptive and takes time that could be used elsewhere. We found this issue when running regression tests for other components that use dovecot in their testing environment which means that we would have to rewrite other tests too. Which is in fact just a reiteration of the first paragraph. Cheers, Michal Hlavinka
pigeonhole tests crashing in deleteheader.svtest
Hi,
when trying to build dovecot 2.3.5.1 pigeonhole testsuite crashes in
Test case: ./tests/extensions/editheader/deleteheader.svtest:
1: Test 'Deleteheader - nonexistent' SUCCEEDED
2: Test 'Deleteheader - nonexistent (match)' SUCCEEDED
3: Test 'Deleteheader - one' SUCCEEDED
4: Test 'Deleteheader - two (first)' SUCCEEDED
5: Test 'Deleteheader - two (last)' SUCCEEDED
6: Test 'Deleteheader - :index' SUCCEEDED
7: Test 'Deleteheader - :index :last' SUCCEEDED
8: Test 'Deleteheader - implicit keep' SUCCEEDED
make: *** [Makefile:1190:
tests/extensions/editheader/deleteheader.svtest] Segmentation fault
(core dumped)
Let me know if you need more debug information.
Cheers
Michal Hlavinka
#0 0x7f9924faea8a in __strlen_sse2 () from /lib64/libc.so.6
#1 0x7f992514fdd2 in smtp_address_clone (pool=0x7f992528dce0
, src=src@entry=0x7ffd30eace10) at smtp-address.c:632
#2 0x55f7330916b3 in testsuite_message_set_data
(mail=0x55f73486f848) at testsuite-message.c:96
#3 0x55f7330918b9 in testsuite_message_set_file
(renv=renv@entry=0x55f734856ac0, file_path=) at
testsuite-message.c:139
#4 0x55f7330931cc in testsuite_smtp_get
(renv=renv@entry=0x55f734856ac0, index=) at
testsuite-smtp.c:171
#5 0x55f73309566c in cmd_test_message_smtp_operation_execute
(renv=0x55f734856ac0, address=) at cmd-test-message.c:404
#6 0x7f992543f371 in sieve_interpreter_operation_execute
(interp=0x55f734856a68) at sieve-interpreter.c:911
#7 sieve_interpreter_continue (interp=0x55f734856a68, interrupted=0x0)
at sieve-interpreter.c:949
#8 0x7f992543f5d1 in sieve_interpreter_run (interp=0x55f734856a68,
result=) at sieve-interpreter.c:999
#9 0x55f73308f670 in testsuite_run (msgdata=,
ehandler=, senv=0x7ffd30eacfa0, sbin=) at
testsuite.c:73
#10 main (argc=, argv=) at testsuite.c:203
(gdb) up
#1 0x7f992514fdd2 in smtp_address_clone (pool=0x7f992528dce0
, src=src@entry=0x7ffd30eace10) at smtp-address.c:632
632 dsize = strlen(src->domain) + 1;
(gdb) p *src
$4 = {localpart = 0x55f73480cdc8
"/tmp/dsieve-testsuite.1553794316.30960/smtp/0.eml", domain = 0x1
}
Re: Regression ACL & namespace prefix
Hi,
were you able to reproduce this problem? Do you need more information to
reproduce this?
Cheers,
Michal Hlavinka
On 3/12/19 3:29 PM, Michal Hlavinka wrote:
Hi,
thanks for the answer. I think your environment was not set up correctly
to reproduce this bug. I've retested with 2.3.5 and I can still
reproduce it. I've attached a script that will configure everything for
testing and if you have a virtual machine available, you can use it
directly (it expects linux with systemd for dovecot restart).
relevant section from config:
namespace {
hidden = no
list = yes
location = maildir:/var/mail/pub
prefix = pub/
separator = /
type = public
}
this expects maildir directly in pub:
/var/mail/pub/cur
/var/mail/pub/new
/var/mail/pub/tmp
as it uses '/' separator and there could be subfolders, it should look
for .DEFAULT file in global acls directory which it does not in your
debug output
doveadm(testuser): Info: Mailbox '' is in namespace 'pub/'
doveadm(testuser): Info: All message flags are shared across users in
mailbox
doveadm(testuser): Debug: acl vfile: file
/etc/dovecot/global-acls//.DEFAULT
not found
doveadm(testuser): Debug: acl vfile: file /var/mail/pub/dovecot-acl not
found
doveadm(testuser): Info: User testuser has no rights for mailbox
doveadm(testuser): Error: User testuser is missing 'lookup' right
doveadm(testuser): Info: Mailbox pub is NOT visible in LIST
in this output see that it checks this location:
acl vfile: file /etc/dovecot/global-acls//.DEFAULT not found
instead of
/etc/dovecot/global-acls/pub/.DEFAULT
this is caused by line in
src/plugins/acl/acl-backend-vfile.c: acl_backend_vfile_object_init(...)
vname = *name == '\0' ? "" :
mailbox_list_get_vname(_backend->list, name);
and because name is empty, it will not use the "pub" prefix in the path.
If I'd test acl for "pub/subfolder" that condition would have different
result and bug would not trigger:
doveadm(testuser): Debug: acl vfile: reading file
/etc/dovecot/global-acls/pub/subfolder/.DEFAULT
For testing I use this acl configuration:
cat /etc/dovecot/global-acls/pub/.DEFAULT
user=testuser l
but as this acl file location is not found by dovecot, content should
not matter.
Cheers,
Michal Hlavinka
On 3/7/19 7:00 PM, Aki Tuomi via dovecot wrote:
I tested with release 2.3.5, and
doveadm -Dv acl debug -u testuser pub doveadm(testuser): Debug: acl
vfile: file /etc/dovecot/global-acls/pub/INBOX not found
doveadm(testuser): Debug: acl vfile: file
/home/vmail/pub/Mail/mailboxes/INBOX/dbox-Mails/dovecot-acl not
found doveadm(testuser): Debug: acl vfile: file
/etc/dovecot/global-acls/ not found doveadm(testuser): Debug: acl
vfile: file /home/vmail/pub/Mail/mailboxes/dovecot-acl not found
so our advice is to upgrade into 2.3.5, as 2.2.36 is no longer in
development.
Aki
On 7 March 2019 19:47 Aki Tuomi via dovecot
wrote:
Sorry, we have not yet been able to look into this..
It's now in our internal system as DOP-966
Aki
On 7 March 2019 17:31 Michal Hlavinka via dovecot
wrote:
Hi, any progress with this issue? Do you need more information to
debug and fix this?
Cheers Michal Hlavinka
On 9/18/18 4:10 PM, Michal Hlavinka wrote:
Hi
tl;dr: Seems that for Global ACL directory, namespace prefix is
not part of the path, when looking for acl file.
Long version:
We're planning to update dovecot in next os update to 2.2.36
and while going through regression testing, we found a problem
with ACL configuration combined with namespace.
Test uses "Global ACL directory" configuration.
Relevant configuration part: mail_location = maildir:~/Maildir
namespace inbox { hidden = no inbox = yes list = yes location
= prefix = separator = / } namespace { hidden = no list = yes
location = maildir:/var/mail/pub prefix = pub/ separator = / type =
public }
mail_plugins = acl
protocol imap { mail_plugins = $mail_plugins acl imap_acl } plugin
{ acl = vfile:/etc/dovecot/global-acls }
ACL config file is stored at: /etc/dovecot/global-acls/pub/.DEFAULT
when trying to examine "pub", it is denied: fetchmail: IMAP>
A0005 EXAMINE "pub" fetchmail: IMAP< A0005 NO Mailbox doesn't
exist: pub (0.001 + 0.000 secs).
# doveadm acl debug -u d2 pub doveadm(d2): Info: Mailbox '' is
in namespace 'pub/' doveadm(d2): Info: Mailbox path:
/var/mail/pub doveadm(d2): Info: All message flags are shared
across users in mailbox doveadm(d2): Info: User d2 has no
rights for mailbox doveadm(d2): Error: User d2 is missing
'lookup' right doveadm(d2): Info: Mailbox pub is NOT visible in
LIST
because it did not find acl file: imap(d2): Debug: Namespace :
type=public, prefix=pub/, sep=/, inbox=no, hidden=no, list=yes,
subscriptions=yes location=maildir:/var/mail/pub imap(d2):
Debug: maildir++: root=/var/mail/pub, index=, indexpvt=, control=,
inbox=, alt=
Re: pigeonhole tests crashing in deleteheader.svtest
On 3/28/19 6:41 PM, Aki Tuomi via dovecot wrote: On 28 March 2019 19:40 Michal Hlavinka via dovecot wrote: Hi, when trying to build dovecot 2.3.5.1 pigeonhole testsuite crashes in Which version of pigeonhole are you using? latest available - 0.5.5
Re: pigeonhole tests crashing in deleteheader.svtest
On 4/12/19 12:48 AM, Stephan Bosch wrote: On 29/03/2019 10:23, Michal Hlavinka via dovecot wrote: On 3/28/19 6:41 PM, Aki Tuomi via dovecot wrote: On 28 March 2019 19:40 Michal Hlavinka via dovecot wrote: Hi, when trying to build dovecot 2.3.5.1 pigeonhole testsuite crashes in Which version of pigeonhole are you using? latest available - 0.5.5 Hmm, what platform are you compiling this on and what compiler are you using? Fedora Linux, x86_64, kernel 5.0.6, glibc 2.29.9000, gcc 9.0.1 Looking at the backtrace, it seems it's probably related to https://dovecot.org/pipermail/dovecot/2019-January/114494.html
sieve crashes when two optional include scripts are missing
Hi, we've found an issue with sieve plugin. When script includes two missing optional scripts, it causes crash. For reproducing the issue, script names must belong to same hash table node, so either two scripts with same name or scripts where 'hash(name) % table->size' results in same value, like missing_a and missing_aa in reproducer below. Reduced reproducer: cat >dovecot.min.conf <reproducer.sieve < empty sieve-test -c dovecot.min.conf reproducer.sieve empty any test mail would do, but empty file is enough for reproducer # return sblock->id causes the crash as sblock is NULL backtrace: (gdb) bt #0 sieve_binary_block_get_id (sblock=0x0) at src/lib-sieve/sieve-binary.c:421 #1 ext_include_execute_include (renv=0x555bbed8, include_id=1, flags=EXT_INCLUDE_FLAG_OPTIONAL) at plugins/include/ext-include-common.c:696 #2 opc_include_execute (renv=0x555bbed8, address=0x555bbf10) at plugins/include/cmd-include.c:399 #3 sieve_interpreter_operation_execute (interp=0x555bbe88) at src/lib-sieve/sieve-interpreter.c:901 #4 sieve_interpreter_continue (interp=0x555bbe88, interrupted=0x0) at src/lib-sieve/sieve-interpreter.c:959 #5 sieve_interpreter_start (interp=0x555bbe88, result=0x555b9230, interrupted=0x0) at src/lib-sieve/sieve-interpreter.c:1049 #6 sieve_interpreter_run (interp=0x555bbe88, result=0x555b9230) at src/lib-sieve/sieve-interpreter.c:1057 #7 sieve_run (sbin=0x5558ee18, result=0x555b9230, eenv=0x7fffe890, ehandler=0x5558c338) at src/lib-sieve/sieve.c:357 #8 sieve_test (sbin=0x5558ee18, msgdata=0x7fffe9f0, senv=0x7fffea30, ehandler=0x5558c338, stream=0x555b2cd0, flags=SIEVE_EXECUTE_FLAG_LOG_RESULT) at src/lib-sieve/sieve.c:598 #9 main (argc=5, argv=0x55567a10) at src/sieve-tools/sieve-test.c:391 issue seems to be caused by lib-sieve/plugins/include/ext-include-common.c: ext_include_generate_include on first pass (script) the check for script already compiled into binary at 529: included = ext_include_binary_script_get_include_info(binctx, script); returns NULL, so code goes through 'else' block where it hits sieve_script_is_open(script) check. It includes script with NULL block, returns 0 so caller cmd_include_generate does not emit anything. On second pass the above 'included' check returns first missing script, it goes through true block where it just checks flags and returns non-zero, so caller this time goes through the emit code block and the previously included NULL sblock gets referenced causing crash later. Note: despite scripts have different name, they pass the "same script" check because sieve_file_script_equals compares 0==0 dev & inode numbers as scripts do not exist. This is why scripts do not have to have same names. Side effect of this is that as missing_a and missing_aa are treated like the same script, only first one is linked in compiled svbin. Which means that if missing_aa reappears later, svbin won't get recompiled. Another manifestation of the issue is when included missing_a script is present when main script is compiled and later missina_a is removed again. During execution, script is not recompiled and it aborts for hash table dupe check: sieve_binary_open->ext_include_binary_script_include->hash_table_insert There are several ways how to solve this. I've tried a few, but there were other corner cases that appeared. One tried way was for example ext_include_generate_include in the 'if (included)' replicate the check sieve_script_is_open(...) from else block, just check flags, no include and set result to 0. Another way to solve this is to return from ext_include_execute_include early if sblock is NULL just before it tries to derefernce it, similarly as it does if it fails 'once' check. Same for dumping in opc_include_dump. Whilst the first approach seems a bit better, it won't stop crashing in existing environments as it won't trigger svbin recompilation and svbin would fail. This means that the second soultion is sort of needed anyway. This still won't solve the problem with different missing scripts as only first one would be able to trigger recompilation when file becomes available. Just including both in the mentioned function won't work either as they would still be evaluated as same and hash table anti-dupe check would trigger abort. So some changes in script comparison seem needed anyway. This is what I've used in my approach. Return early from ext_include_execute_include and opc_include_dump if sblock is NULL and change sieve_file_script_equals to compare also script->location for missing scripts (when inode is 0). Let me know if you need more information. Cheers, Michal Hlavinka ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
