Hi, On Tue, Jun 16, 2009 at 11:13:26PM +0200, Arne Babenhauserheide wrote: > Am Montag, 15. Juni 2009 00:38:16 schrieb olafbuddenha...@gmx.net:
> > I must admit that the ratio is probably even worse in my case... I > > got very mixed results with bug reports to various projects in the > > past, which is not exactly encouraging :-( > > Maybe I just had better luck... most of my bugreports where either > well received or ignored... Well, "ignored" is the worst possible response to a bug report... > > > > Though I tend to believe that it could be improved at least > > > > partially, at the expense of flexibility, by enforcing certain > > > > fixed limits on users, processes etc. like other UNIX systems > > > > do. > > > > > > Can that be done in a way which can easily be undone once a proper > > > framework is in place? > > > > Adapting the system to use such a framework would probably require > > touching the same places anyways, so I guess it's not a problem. > > Should I add it as a feature request or such? I guess it would be useful to add it to the Savannah task tracker... Note though that there is no consensus about this. It is my *personal* believe that this is doable and worthwhile. > > > This fragility does sound like it would make the Hurd completely > > > unusable in most situations, > > > > Nah, it's not that bad. Usually you don't have actively malicious > > local users on your system; so that leaves us with bugs in the > > software, which need to be fixed anyways... > > If it means that the users need to be malicious, the issue is not as > much of a problem, I think. It sounded to me as if it could be killed > by a simple user- error. Usually it's not user errors, but bugs in software that cause port leaks. But user errors *can* cause resource exhaustion: > Naturally having limits which keep userfs from shooting the whole > system would be nice anyways - even if only in the case that a user > unintentionally creates a fork-bomb or similar (I once managed to > shoot my system with one, though I only wanted to try the python > subprocess module ;) ) This is one type of user error that even mainstream systems aren't safe against in standard configurations -- which IMHO is a pretty clear indication that this is acceptable in some cases at least... -antrik-