lkml.org 
[lkml]   [2001]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH] Single user linux
    Date
    first, i think i owe you guys apology for didn't make myself
    clear, which is going harder if you irritated.
    even my subject went wrong, as the patch isn't really about
    single user (which confuse some people).

    for those who didn't read that patch, i #define capable(),
    suser(), and fsuser() to 1. the implication is all users
    will have root capabilities.

    then i tried to bring up the single user thing to hear
    opinions (not flames). and by that, i actually didn't mean
    to have users share the same uid/gid 0. i know somebody
    will need to differentiate user.

    so when everybody suggested playing with login, getty, etc.
    i know you have got the wrong idea. if i wanted to play
    on user space, i'd rather use capset() to set all users
    capability to "all cap". that's the perfect equivalent.

    so the user space solution (capset()) works, but then came
    the idea to optimize away. that's what blow everybody up.
    don't get me wrong, i always agree with rik farrow when he
    wrote in ;login: that we should build software with security
    in mind.

    but i also hate bloat. lets not go to arm devices, how about
    a notebook. it's a personal thing, naturally to people who
    doesn't know about computer, personal doesn't go with multi
    user. by that i mean user with different capabilities, not
    different persons.

    i haven't catch up with all my mails, but my response to
    some:
    - linux is stable not only because security.
    - linux was designed for multi-user, dos f.eks. is designed
    for personal use, so does epoc, palmos, mac, etc.
    - i even use plan9 with kfs restrictions disabled sometimes,
    cause i don't have cpu server, auth server, etc.
    - with that patch, people will still have authentication.
    so ssh for example, will still prevent illegal access, if
    you had an exploit you're screwed up anyway.
    sure httpd will give permission to everybody to browse
    a computer, but i don't think a notebook need to run it.

    so i guess i deserve opinions instead of flames. the
    approach is from personal use, not the usual server use.
    if you think a server setup is best for all use just say so,
    i'm listening.


    > It would be far more interesting to rip out all trace of
    security.
    > That would include the kernel memory access checking,
    parts of the
    > task struct, filesystem and VFS code, and surely much
    more.

    i did say it clearly that i have other changes which i know
    won't be a clean patch (too many #ifdefs). f.eks. on my
    computer i didn't even compile user.c in, i don't have
    user_struct. filesystem and vfs code are affected by that
    patch already. memory access is important of course.

    > Then you can try to show a measurable performance
    difference.

    nah, performance was never my consideration. i do save about
    3kb from my zImage, but i'm not interested.


    imel (writing from a
    webmail)

    ----------------------------------------------------
    This email was sent using http://webmail.cbn.net.id/


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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