lkml.org 
[lkml]   [2000]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: How a normal user can crash any linux system
    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 from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:57    [W:0.024 / U:29.924 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site