dovecot Digest, Vol 177, Issue 55

Thu Jan 25 16:31:57 EET 2018

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 at 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 at dovecot.org> wrote:
>
>> Send dovecot mailing list submissions to
>>         dovecot at 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 at dovecot.org
>>
>> You can reach the person managing the list at
>>         dovecot-owner at dovecot.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of dovecot digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Re: Panic: data stack: Out of memory when allocating bytes
>>       (Josef 'Jeff' Sipek)
>>    2. Re: 777 permissions on mailbox, subfolders subfiles new
>>       emails (Nikolai Lusan)
>>    3. Re: problem with lda (Stephan Bosch)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Wed, 24 Jan 2018 17:39:36 -0500
>> From: Josef 'Jeff' Sipek <jeff.sipek at dovecot.fi>
>> To: Thomas Robers <robers at tutech.de>
>> Cc: dovecot at dovecot.org
>> Subject: Re: Panic: data stack: Out of memory when allocating bytes
>> Message-ID: <20180124223936.GE14966 at 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:
>> ...
>> > > > 1. 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.
>>
>> > > > 2. 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.
>> > > > 3. 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 at lusan.id.au>
>> To: dovecot at dovecot.org
>> Subject: Re: 777 permissions on mailbox, subfolders subfiles new
>>         emails
>> Message-ID: <1516849780.4714.5.camel at 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 at 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 at rename-it.nl>
>> To: Infoomatic <infoomatic at gmx.at>, dovecot at dovecot.org
>> Subject: Re: problem with lda
>> Message-ID: <2544728b-5441-c163-34fd-bd155e28f591 at rename-it.nl>
>> Content-Type: text/plain; charset=utf-8
>>
>> Op 1/24/2018 om 5:30 PM schreef Infoomatic:
>> > 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 at 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
>> parameter: Missing domain
>> >
>> > and the alert message is only sent to virusalert at 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 at 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 at dovecot.org
>> https://dovecot.org/mailman/listinfo/dovecot
>>
>> ------------------------------
>>
>> End of dovecot Digest, Vol 177, Issue 55
>> ****************************************
>>
>
>
>
> --
> zxzzzzzzzzzzzzz
>

-- 
zxzzzzzzzzzzzzz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dovecot.org/pipermail/dovecot/attachments/20180125/e18fe337/attachment-0001.html>