Start new session...
Oswald Buddenhagen
ossi at kde.org
Sat Oct 12 04:55:30 BST 2002
On Sat, Oct 12, 2002 at 12:11:48AM +0200, Ingo Klöcker wrote:
> > this is not a completely new feature, it's only _one more_ way to
> > exploit unix's multi-user capabilities.
>
> It is a completely new feature of kdm as far as I can tell.
>
yes. since kde 3.0. the only thing i changed there now was disabling a
misfeature (full-automatic reserve display start) to replace it with the
stuff you're now fighting against.
> If everything, that is achievable with other means Unix provides,
> isn't a new completely new feature then almost every new feature could
> go in during feature freeze (because "this is not a completely new
> feature").
>
the "feature similarity" has _nothing_ to do with the freeze breach.
so this comparision is simply void.
> > particularily, you were able to have
> > configured multiple xservers at the same time from the beginngings of
> > time. the only new thing about this feature is, that new xservers are
> > started on-demand by kdm, as opposed to running all the time or being
> > started manually with "startx -- :[1|2|...]" from the command line.
>
> The difference is that back then only experienced users could nuke other
> users. But experienced users usually no about the implications of their
> actions. Now every user can nuke other users.
>
that's wrong. an unexperienced (or simply reckless) user always could
nuke everybody logged into the machine - may it be a remote user or some
experienced user who started another xsession while the first session was
locked. the only new situation is now, that a user sees a locked session
and can start another one even though he is unexperienced. whether he
shuts down the box at the end has nothing to do with experience, but
with bad memory.
> And since "dummy" users (like you call them below) don't now about the
> implications of their actions (like shutting down while still another
> session from another user is open) they have to be warned about these
> implications.
>
you now defined "dummy" users to be simply dumb users, which is simply
not what i said (why should i use quotes then?). every user with an iq
above room temperature understands, that it is a bad thing (tm) to nuke
someones session. he only has to think a second about how he would like
it if somebody simply nuked his session.
so we are back to only one simple (in terms of explaining it) problem:
the user does not know/remember, that there is a session in the
background.
> > > The problem is: You can nuke yourself or other people without
> > > knowing you did.
> >
> > as you could before. you can nuke other manually started x-servers,
> > you can nuke vts you forgot to close and you can nuke other users
> > that logged into your machine remotely.
>
> Yeah, right. So now let's add just another way to nuke other users,
> not. The ultimate goal should be to make it almost impossible to nuke
> other users in any way and not to add more ways to do this.
>
imagine you have 10 armed enemies in front of you. now another one with
a somewhat bigger gun appears. sure, you're missing a really strong
armor, but does it really help you if that one guy with the bigger gun
stays away?
yes, i added one more way to exploit a risky feature and we _still_ have
no protection. so what?
having said this, i admit that i lied. kdm already has such a
protection. just that it was shot down and disabled by default, as it
was widely condidered to be too complicated to tell kdm in advance what
it should do in case other sessions are running. i could remove the
burden of making a decision from the user by making this option
hard-settable by the admin, but then the average user would just wonder
"why is this f***ing box not shutting down" and resort to other means of
shutting down the box. and the infrastructure to make a really
interactive shutdown that asks the user only if there actually _are_
other sessions is still not in place. yes, i suck. big time.
> You are exaggerating.
>
i'm not the only one here. ;)
> All we ask from you is to make it as hard as possible for newbies to
> do something stupid.
>
sure. i will. but i also have only limited resources.
> If you can't do this for KDE 3.1 then please postpone your nice
> feature until KDE 3.2.
>
yes. i'm a bad ass, as i commited a half-finished feature (long ago) and
additionally did not add another feature to make it bullet-proof, yet.
i'm sure the users that like the feature even as-is are wishing me to
hell.
greetings
--
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.
More information about the kde-core-devel
mailing list