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
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
i haven't catch up with all my mails, but my response to
- 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,
> It would be far more interesting to rip out all trace of
> That would include the kernel memory access checking,
parts of the
> task struct, filesystem and VFS code, and surely much
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
nah, performance was never my consideration. i do save about
3kb from my zImage, but i'm not interested.
imel (writing from a
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 firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Apr 30 2001 - 21:00:13 EST