On Mon, 22.07.13 19:19, Miloslav Trmač (mitr(a)volny.cz) wrote:
On Mon, Jul 22, 2013 at 7:00 PM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
> On Mon, 22.07.13 18:43, Miloslav Trmač (mitr(a)volny.cz) wrote:
>
>> On Mon, Jul 22, 2013 at 6:36 PM, Lennart Poettering
>> <mzerqung(a)0pointer.de> wrote:
>> > On Fri, 19.07.13 20:22, Miloslav Trmač (mitr(a)volny.cz) wrote:
>> >
>> >> On Fri, Jul 19, 2013 at 8:16 PM, Matthew Miller
>> >> <mattdm(a)fedoraproject.org> wrote:
>> > Where "expected to do" means effectively route it to /dev/null?
>>
>> It's actually less similar to /dev/null than log files are - log files
>> are rotated and deleted, mail stays in the mail boxes until explicitly
>> deleted (or space runs out).
>
> Well, so it's even a DoS... Just find some trigger to generate a lot of
> mails to root and /var will eventually fill up, even beyond those 10%
> reserved for root, since well, mail to root is accounted to root...
My concern about this proposal doesn't actually depend on local
delivery, it _could_ go to /dev/null by default for all I care.
What a crappy API is that?
I'll note, however, that "this is a DoS" is rarely a
convincing
argument - the only practical way to combat a DoS is to impose some
kind of limit, which is just a DoS of a different kind. You get to
choose _what_ kinds of DoS your computer will be subject to, but with
finite CPU power and storage you can't avoid DoS situations.
The point I am trying to make is that if you have something that is
vulnerable to a DoS attack you need to have a strategy to handle
that. You need to keep the attack local, isolated as much as you can
from the rest of the system and other clients. A strategy of "hey, yeah,
let's queue this all up and allow unprivileged clients to bring down the
entire system by easily flooding /var" is a bad strategy, an
embarrassingly bad one. It's a DoS that is the opposite of local.
And, philosophically, silently losing data is generally much worse
than requiring manual intervention for the system to run when space
runs out. (Not that the mails we sent by default are _that_ valuable,
though.)
Mirek
If we drop data we definitely always need to keep track of that and
account it, no doubt. (journald does keep track of messages dropped via
per-service/per-priority ratelimit, and it will tell you how far back
history in the logs reach)
Lennart
--
Lennart Poettering - Red Hat, Inc.