On Mon, 22.07.13 19:19, Miloslav Trmač (mitr@xxxxxxxx) wrote: > On Mon, Jul 22, 2013 at 7:00 PM, Lennart Poettering > <mzerqung@xxxxxxxxxxx> wrote: > > On Mon, 22.07.13 18:43, Miloslav Trmač (mitr@xxxxxxxx) wrote: > > > >> On Mon, Jul 22, 2013 at 6:36 PM, Lennart Poettering > >> <mzerqung@xxxxxxxxxxx> wrote: > >> > On Fri, 19.07.13 20:22, Miloslav Trmač (mitr@xxxxxxxx) wrote: > >> > > >> >> On Fri, Jul 19, 2013 at 8:16 PM, Matthew Miller > >> >> <mattdm@xxxxxxxxxxxxxxxxx> 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
