Date: Thu, 23 Mar 2000 14:54:01 +0100 (MEZ) From: "Dr. Michael Weller" <eowmob@exp-math.uni-essen.de> To: linux-kernel@vger.rutgers.edu, hackers@FreeBSD.ORG Subject: Re: How a normal user can crash any linux system Message-ID: <Pine.A32.3.95.1000323140147.54444A-100000@werner.exp-math.uni-essen.de> In-Reply-To: <200003230008.QAA94325@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
OK, I know I should not answer to this thread, but I do it anyway, sorry for that. On Wed, 22 Mar 2000, Matthew Dillon wrote: > Generally speaking if a user wants to crash a machine, he can crash > a machine. We've probably 'fixed' a dozen crashability holes in the [...] > For example, just before the 4.0 release it was found that one can > easily run the kernel out of vm_map_entry resources by mmap()ing > hundreds of thousands of tiny files. We added a vm.max_proc_mmap > sysctl to control that. And it still quite easy to bypass the datasize > resource limit through the use of MAP_ANON mmap's. [...] The point is IMHO (all I say here is IMHO, of course), Unix (Ok, Linux Is Not UniX) Unix is intended as an OS to enable a capable user & programmer to use the computer as a very powerful tool. You see this everywhere in the design of Unix. The scripts and possibility of filters everywhere in the system setup and daemons show that and allow the capable person to manipulate and do everything. Of course this is not simple, the OS is designed to be used by a capable user, not for the click a button and hope it does the right thing person. In addition, each single user should be able to get the maximum usage of the machine.. Unfortunately there are some obvious unsolvable conceptional problems if each user can get the maximum usage of the machine for him. Another design issue of Unix is that most of the system is readable by anyone. Normally any user can see which processes everyone else runs, for example. All this is ok in the situation where you have a workgroup of people using a machine to get the maximum use of it. Unix is not designed to have logged in a community of hostile users. And you cannot really make Unix behave like that. Unix does not want to be like that actually: That level of hostility of the os to users would hinder users in a normal context to make good use of the machine. The point here is like always: there does not exist the solution to everything: C (or C++) is a nice language, I like it myself very much.. for example. However, it cannot do everything.. There are cases where Lisp, Fortran maybe Java.. a shell script, whatever... is better suited.. Does that mean you would pervert C to have all the features of these languages? No, you don't. Actually you cannot do that. Some features are actually contrary to each other. So a sensible programmer uses the language most fit to the problem he wants to solve. Now, if you have a bunch of hostile users, you don't let them login into your unix. You don't use unix actually.. You could run one of these old mainframe OS's.. maybe the old IBM VM/CMS.. every user gets actually a small virtual PC with a single threaded CPU and some fixed amount of memory.. Well... you lock up your login session... you can't just login another time.. (no other process possible for you).. you dial up the operator and tell him zillions of excuses and how stupid you are and he will kill your old session.. Oh.. a bug in the OS.. your session is unkillable... don't worry.. at the scheduled maintenance next week the machine is rebooted.. So what does that mean? Unix is just not the right OS for what you want to do and cannot be it and does not want to be it. Is that a problem? Not really.. just choose another OS. Actually, you could achieve what you want under unix by not giving people a full login account but give them a special application as login shell which only allows very limited operations. Loading or coding an own application and run it should by far not be one of their options. Maybe some very restrictive scripting language which is interpreted in a sandbox (a dialect of Java, maybe?) The same holds for the undieable overcommitment thread. Many new linux users come from a single threaded DOS or home computer OS scenario. They just don't understand unix memory semantics. I had the same problem when I first came into contact with unix (not linux those days).. However, I was first surprised only, then informed myself and realized why it was made this way and realized it is indeed useful for me. Actually, in those old days, we used to have some machine with a non-overcommitting unix.. It was a pain.. I tell you.. we could simply not use all the memory the machine actually had.. just because the fork() and general process semantics of Unix does not work w/o overcommitting. That machine always had megs of never used swapspace around (which was pretty expensive those days). It is a simple decision: you overcommit memory or you don't use the unix API. This does not mean that one should not discuss other ways to deal with OOM.. you may have some quotas or whatever.. I really like the sending of SIGDANGER in case some low watermark is hit and each process can decide to to catch it, notice with some syscall that memory is low and react accordingly.. still it is impossible to completely get rid of overcommitment.. IF you want to have the powers of a unix OS! So, please.. this list is about creation of a unix style os.. if that is not what you need.. go away.. BTW, I must admit I strongly dislike the 'linux world domination' attitude of some people. There is no OS for everything. Not linux, not anything else. This attitude makes people only think linux must be the solution for them when it is not. I don't want a linux OS in my dishwasher as much as I don't want a Windows in there. Best wishes and peace to everyone, Michael. -- Michael Weller: eowmob@exp-math.uni-essen.de, eowmob@ms.exp-math.uni-essen.de, or even mat42b@spi.power.uni-essen.de. If you encounter an eowmob account on any machine in the net, it's very likely it's me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.A32.3.95.1000323140147.54444A-100000>