Re: dovecot Digest, Vol 177, Issue 55
No reason to tell me about security, I just need chmod for my tests. Where to change it ?
On Thu, Jan 25, 2018 at 12:00 PM, dovecot-request@dovecot.org wrote:
Send dovecot mailing list submissions to dovecot@dovecot.org
To subscribe or unsubscribe via the World Wide Web, visit https://dovecot.org/mailman/listinfo/dovecot or, via email, send a message with subject or body 'help' to dovecot-request@dovecot.org
You can reach the person managing the list at dovecot-owner@dovecot.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of dovecot digest..."
Today's Topics:
- Re: Panic: data stack: Out of memory when allocating bytes (Josef 'Jeff' Sipek)
- Re: 777 permissions on mailbox, subfolders subfiles new emails (Nikolai Lusan)
- Re: problem with lda (Stephan Bosch)
Message: 1 Date: Wed, 24 Jan 2018 17:39:36 -0500 From: Josef 'Jeff' Sipek jeff.sipek@dovecot.fi To: Thomas Robers robers@tutech.de Cc: dovecot@dovecot.org Subject: Re: Panic: data stack: Out of memory when allocating bytes Message-ID: 20180124223936.GE14966@meili Content-Type: text/plain; charset=us-ascii
On Wed, Jan 24, 2018 at 18:55:47 +0100, Thomas Robers wrote:
Am 23.01.2018 um 20:07 schrieb Josef 'Jeff' Sipek:
On Tue, Jan 23, 2018 at 14:03:27 -0500, Josef 'Jeff' Sipek wrote:
On Tue, Jan 23, 2018 at 18:21:38 +0100, Thomas Robers wrote: ...
- Do you have any idea what the imap process was doing at the time of the allocation failure?
Yes perhaps. We use shared mailboxes and at the time of failure the imap process is reading acl files in a shared mailbox (and subfolder). This shared mailbox has about 2800 subfolder and the acl files are read in about 10sec and and during this reading the imap process dies with the already mentioned error. It seems it has something to do with the shared mailbox, because since yesterday morning 5 core dumps have been created, 4 of them by one user accessing the shared mailbox and 1 by the user who is the owner of the shared mailbox. No other mailboxes are affected until now.
Based on the stack trace, the client was creating a new mailbox, which caused an acl list rebuild, which ended up triggering this oddly sized allocation.
- You snipped all the important parts of the back trace. :) It *starts* on the line: #0 0x00007f73f1386495 in raise () from /lib64/libc.so.6
In case you haven't used gdb before... after starting up gdb, run "bt full" at the gdb prompt. That'll print out a very detailed backtrace. (You might want to sanity check it to make sure there aren't any user passwords in it before posting it here...)
Yes, sorry I'm not very familiar in using gdb, but here is the full backtrace:
It looks like the binaries are stripped. There should be a "debug" package you can install with symbol information. Then, the backtrace should be much more helpful.
Having the backtrace should help answer question number 1.
- How big is this process when it dies?
I don't know which imap process dies beforehand so how do i get this information?
The size of the core file will give you an general idea. gdb can also print out lots of info via "maintenance info sections", but I don't think that'll help figuring out why things blow up.
Jeff.
-- Keyboard not found! Press F1 to enter Setup
Message: 2 Date: Thu, 25 Jan 2018 13:09:40 +1000 From: Nikolai Lusan nikolai@lusan.id.au To: dovecot@dovecot.org Subject: Re: 777 permissions on mailbox, subfolders subfiles new emails Message-ID: 1516849780.4714.5.camel@lusan.id.au Content-Type: text/plain; charset="UTF-8"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hi,
On Thu, 2018-01-25 at 00:35 +0200, Matthew Brown wrote:
What I have to change, so dovecot on new email create, sets chmod 777 on Mailbox and all subfolders subfiles all new emails/sent emails etc.
This is a really bad idea. It is possible to setup in dovecot if you're using dovecot as your LDA. The only reason I can think of for anything close to this is virtual mailboxes ... and even then I set things up with a specific user to own the files and set them as 770 for the directories and 660 for the files. With that setup dovecot limits users to their own mail directories with values returned via the passdb/userdb.
As a general rule anything on a *nix system that is chmod 777 is to be avoided - it's a massive security risk.
Nikolai Lusan nikolai@lusan.id.au -----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAlppSnQACgkQ4ZaDRV2V L6To/BAAjKeTi6reaRrcSClKm6PEbgewtF1KvHgO1zr+hv9T2XOnVGFSajeFwSXR rDSXGQ/H9s97KDGZB4VKxuSKZsDRFkF9u7ILttuXOgj8kG8XZl4sqg/w0FIrTC1K GD8T0TZWSJGFIzrLXTpgzoO1LeQXIuXgnZIMbcaneCHKZc1do/GwQ4DEFVdUnxRJ n+76nbs8RdQwZKGXYGGTU/BXPniTSW1pmTFxnlruxE7fuWBYeEyQGQRke/CT2rFF ET+d7LlV4Nds6eGjalyf7m5tCNS87Zm78xegANuMNaMdzPI8NlbnFO82bAlC7kP/ WkCFSfhJL3s9daEnMWT/dxY2lNKy3kTyOZssXM6ROkNhOFRipNwRr77tO6qzu8l9 pvaVxr8a0pMVQwxGAyW84vS9GWmeMNMMiY0k7XdPSBS/6CVlQm8eUhnDo6GFZoH9 Tbn4XNkEKysbZEjImjXb6eQpRwQLniIULjeyoX8aqmN2sh4kDndLJwjxpz7Jd6v2 j2tuS7+79G9qU8dqpCSwzvWYTteOLJeqJLy6s5F+zf8FHGLcHdNasoo+/Sdzg4+E tZm31wp7iQdzKMwbOnRk9FceYXbb9WjxI1QY+7U11Rx25y44UDPzUYYOL+ZoWOXJ zAr/F9fhUP/u8AubOgOn6BLaguiWcFK0g6HhCqDkVAUibEMzC+0= =YUek -----END PGP SIGNATURE-----
Message: 3 Date: Thu, 25 Jan 2018 09:35:57 +0100 From: Stephan Bosch stephan@rename-it.nl To: Infoomatic infoomatic@gmx.at, dovecot@dovecot.org Subject: Re: problem with lda Message-ID: 2544728b-5441-c163-34fd-bd155e28f591@rename-it.nl Content-Type: text/plain; charset=utf-8
Hello,
I am currently testing the upgrade from our dovecot v2.2.23 to 2.3.0. I have a strange problem with lda. We use bounce mails for internal users if they try to send virus/spammails. The exact same config works with 2.2.23, but not with 2.3.0.
The relevant postfix/master.cf part: dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/opt/dovecot/libexec/dovecot/deliver -d ${recipient} -f ${sender}
On the same machine, with 2.2.23 I get a bounce mail when trying to send a virus, with the subject "VIRUS in message apparently from you (Eicar-Test-Signature)", to both the users inbox as well as to the mailbox of virusalert@ourdomain.internal
With 2.3.0, in the logs I get an error:
relay=dovecot, delay=0.01, delays=0/0/0/0, dsn=5.3.0, status=bounced (command line usage error. Command output: lda: Fatal: Invalid -f
Op 1/24/2018 om 5:30 PM schreef Infoomatic: parameter: Missing domain
and the alert message is only sent to virusalert@ourdomain.internal,
but not to the user who tried to send the mail.
The relevant part of our dovecot.conf: protocol lda { mail_plugins = " quota zlib sieve acl mail_log notify" postmaster_address = postmaster@ourdomain.internal }
Does anyone know how to solve this problem? Or is there a workaround via
postfix/amavis/spamassassin? Any hints are highly appreciated, thanks!
Apparently, the ${sender} has no @domain part. Why?
Regards,
Stephan.
Subject: Digest Footer
dovecot mailing list dovecot@dovecot.org https://dovecot.org/mailman/listinfo/dovecot
End of dovecot Digest, Vol 177, Issue 55
-- zxzzzzzzzzzzzzz
I looked up the source code, and permissions is hardcoded to dovecot, so only recompilation can change the permissions of emails, folders, mailboxes.
On Thu, Jan 25, 2018 at 2:42 PM, Matthew Brown sergey.travolskis@gmail.com wrote:
No reason to tell me about security, I just need chmod for my tests. Where to change it ?
On Thu, Jan 25, 2018 at 12:00 PM, dovecot-request@dovecot.org wrote:
Send dovecot mailing list submissions to dovecot@dovecot.org
To subscribe or unsubscribe via the World Wide Web, visit https://dovecot.org/mailman/listinfo/dovecot or, via email, send a message with subject or body 'help' to dovecot-request@dovecot.org
You can reach the person managing the list at dovecot-owner@dovecot.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of dovecot digest..."
Today's Topics:
- Re: Panic: data stack: Out of memory when allocating bytes (Josef 'Jeff' Sipek)
- Re: 777 permissions on mailbox, subfolders subfiles new emails (Nikolai Lusan)
- Re: problem with lda (Stephan Bosch)
Message: 1 Date: Wed, 24 Jan 2018 17:39:36 -0500 From: Josef 'Jeff' Sipek jeff.sipek@dovecot.fi To: Thomas Robers robers@tutech.de Cc: dovecot@dovecot.org Subject: Re: Panic: data stack: Out of memory when allocating bytes Message-ID: 20180124223936.GE14966@meili Content-Type: text/plain; charset=us-ascii
On Wed, Jan 24, 2018 at 18:55:47 +0100, Thomas Robers wrote:
Am 23.01.2018 um 20:07 schrieb Josef 'Jeff' Sipek:
On Tue, Jan 23, 2018 at 14:03:27 -0500, Josef 'Jeff' Sipek wrote:
On Tue, Jan 23, 2018 at 18:21:38 +0100, Thomas Robers wrote: ...
- Do you have any idea what the imap process was doing at the time of the allocation failure?
Yes perhaps. We use shared mailboxes and at the time of failure the imap process is reading acl files in a shared mailbox (and subfolder). This shared mailbox has about 2800 subfolder and the acl files are read in about 10sec and and during this reading the imap process dies with the already mentioned error. It seems it has something to do with the shared mailbox, because since yesterday morning 5 core dumps have been created, 4 of them by one user accessing the shared mailbox and 1 by the user who is the owner of the shared mailbox. No other mailboxes are affected until now.
Based on the stack trace, the client was creating a new mailbox, which caused an acl list rebuild, which ended up triggering this oddly sized allocation.
- You snipped all the important parts of the back trace. :) It *starts* on the line: #0 0x00007f73f1386495 in raise () from /lib64/libc.so.6
In case you haven't used gdb before... after starting up gdb, run "bt full" at the gdb prompt. That'll print out a very detailed backtrace. (You might want to sanity check it to make sure there aren't any user passwords in it before posting it here...)
Yes, sorry I'm not very familiar in using gdb, but here is the full backtrace:
It looks like the binaries are stripped. There should be a "debug" package you can install with symbol information. Then, the backtrace should be much more helpful.
Having the backtrace should help answer question number 1.
- How big is this process when it dies?
I don't know which imap process dies beforehand so how do i get this information?
The size of the core file will give you an general idea. gdb can also print out lots of info via "maintenance info sections", but I don't think that'll help figuring out why things blow up.
Jeff.
-- Keyboard not found! Press F1 to enter Setup
Message: 2 Date: Thu, 25 Jan 2018 13:09:40 +1000 From: Nikolai Lusan nikolai@lusan.id.au To: dovecot@dovecot.org Subject: Re: 777 permissions on mailbox, subfolders subfiles new emails Message-ID: 1516849780.4714.5.camel@lusan.id.au Content-Type: text/plain; charset="UTF-8"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hi,
On Thu, 2018-01-25 at 00:35 +0200, Matthew Brown wrote:
What I have to change, so dovecot on new email create, sets chmod 777 on Mailbox and all subfolders subfiles all new emails/sent emails etc.
This is a really bad idea. It is possible to setup in dovecot if you're using dovecot as your LDA. The only reason I can think of for anything close to this is virtual mailboxes ... and even then I set things up with a specific user to own the files and set them as 770 for the directories and 660 for the files. With that setup dovecot limits users to their own mail directories with values returned via the passdb/userdb.
As a general rule anything on a *nix system that is chmod 777 is to be avoided - it's a massive security risk.
Nikolai Lusan nikolai@lusan.id.au -----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAlppSnQACgkQ4ZaDRV2V L6To/BAAjKeTi6reaRrcSClKm6PEbgewtF1KvHgO1zr+hv9T2XOnVGFSajeFwSXR rDSXGQ/H9s97KDGZB4VKxuSKZsDRFkF9u7ILttuXOgj8kG8XZl4sqg/w0FIrTC1K GD8T0TZWSJGFIzrLXTpgzoO1LeQXIuXgnZIMbcaneCHKZc1do/GwQ4DEFVdUnxRJ n+76nbs8RdQwZKGXYGGTU/BXPniTSW1pmTFxnlruxE7fuWBYeEyQGQRke/CT2rFF ET+d7LlV4Nds6eGjalyf7m5tCNS87Zm78xegANuMNaMdzPI8NlbnFO82bAlC7kP/ WkCFSfhJL3s9daEnMWT/dxY2lNKy3kTyOZssXM6ROkNhOFRipNwRr77tO6qzu8l9 pvaVxr8a0pMVQwxGAyW84vS9GWmeMNMMiY0k7XdPSBS/6CVlQm8eUhnDo6GFZoH9 Tbn4XNkEKysbZEjImjXb6eQpRwQLniIULjeyoX8aqmN2sh4kDndLJwjxpz7Jd6v2 j2tuS7+79G9qU8dqpCSwzvWYTteOLJeqJLy6s5F+zf8FHGLcHdNasoo+/Sdzg4+E tZm31wp7iQdzKMwbOnRk9FceYXbb9WjxI1QY+7U11Rx25y44UDPzUYYOL+ZoWOXJ zAr/F9fhUP/u8AubOgOn6BLaguiWcFK0g6HhCqDkVAUibEMzC+0= =YUek -----END PGP SIGNATURE-----
Message: 3 Date: Thu, 25 Jan 2018 09:35:57 +0100 From: Stephan Bosch stephan@rename-it.nl To: Infoomatic infoomatic@gmx.at, dovecot@dovecot.org Subject: Re: problem with lda Message-ID: 2544728b-5441-c163-34fd-bd155e28f591@rename-it.nl Content-Type: text/plain; charset=utf-8
Hello,
I am currently testing the upgrade from our dovecot v2.2.23 to 2.3.0. I have a strange problem with lda. We use bounce mails for internal users if they try to send virus/spammails. The exact same config works with 2.2.23, but not with 2.3.0.
The relevant postfix/master.cf part: dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/opt/dovecot/libexec/dovecot/deliver -d ${recipient} -f ${sender}
On the same machine, with 2.2.23 I get a bounce mail when trying to send a virus, with the subject "VIRUS in message apparently from you (Eicar-Test-Signature)", to both the users inbox as well as to the mailbox of virusalert@ourdomain.internal
With 2.3.0, in the logs I get an error:
relay=dovecot, delay=0.01, delays=0/0/0/0, dsn=5.3.0, status=bounced (command line usage error. Command output: lda: Fatal: Invalid -f
Op 1/24/2018 om 5:30 PM schreef Infoomatic: parameter: Missing domain
and the alert message is only sent to virusalert@ourdomain.internal,
but not to the user who tried to send the mail.
The relevant part of our dovecot.conf: protocol lda { mail_plugins = " quota zlib sieve acl mail_log notify" postmaster_address = postmaster@ourdomain.internal }
Does anyone know how to solve this problem? Or is there a workaround
via postfix/amavis/spamassassin? Any hints are highly appreciated, thanks!
Apparently, the ${sender} has no @domain part. Why?
Regards,
Stephan.
Subject: Digest Footer
dovecot mailing list dovecot@dovecot.org https://dovecot.org/mailman/listinfo/dovecot
End of dovecot Digest, Vol 177, Issue 55
-- zxzzzzzzzzzzzzz
-- zxzzzzzzzzzzzzz
participants (1)
-
Matthew Brown