From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Tue, 27 Jan 2015 19:38:46 -0800 To: 9fans@9fans.net Message-ID: <1fccf1df5e46d5fa5235a40a90a001e3@brasstown.quanstro.net> In-Reply-To: References: <0F748B67-FB11-464C-84FA-66B4E0B29918@9.offblast.org> <44900c0d4896622fa8a9411b05efe730@brasstown.quanstro.net> <7A132462-4747-471A-A4BF-D9381E38A4EA@ar.aichi-u.ac.jp> <4c37cf728d5b0e7ae4ebd3c2e0c2cee4@brasstown.quanstro.net> <3a6fb8671dae34eb5b4e0ebe3992bcfd@brasstown.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3cc1cfdc-ead9-11e9-9d60-3106f5b1d025 On Tue Jan 27 16:06:49 PST 2015, arisawa@ar.aichi-u.ac.jp wrote: > we don=E2=80=99t have perfect solution. > nevertheless, we must protect system. why does limiting forks "protect the system"? why must be "protect the sy= stem"? and what does that phrase mean in this context? > if we search ideal (or nearly ideal) solution, we should assign limited= resource to each user. > however this is a big job, I believe. >=20 > current plan9 system is running under shared resource model. > under this model, it is very hard to protect system from evil-minded us= ers. plan 9 has no hope against malicious users. they can fill up your disk, = or use all your memory, too. i believe the quote attributed to presotto is "we don't have quotas. ken just yells at anyone who hogs the jukebox." nonetheless, i have experience running multi-user plan 9 systems, and use= rs were not usually the issue. > keeping this model, we can do something that is, of course, imperfect (= but easy to implement, I believe). > for example: > (a) select processes that should keep running. (with resrcwait flag, fo= r example) > (b) kill processe that failed to be allocated resource if it doesn=E2=80= =99t has resrcwait flag. >=20 > this strategy has following problems: > (1) innocent processes may be killed. > the probability is small if the origin is careless program, but can be = large by evil-mined program. > (2) error return from malloc() and fork() are disabled. i think you've turned a problem with bounded recovery time into a situation where the recovery code itself will inadvertently dos attack it= s users. - erik