Start new session...

[Ingo Klöcker]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 11 October 2002 17:38, Oswald Buddenhagen wrote:
> On Thu, Oct 10, 2002 at 07:15:55PM +0200, Josef Weidendorfer wrote:
> > There's a lot of complexity in this feature.
>
> sure, but this complexity is not unique to this feature. i repeat
> myself, but some people don't seem to understand: 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. 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").

> 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. 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.

> > 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.

> the only concern is, that i made it simpler for the "dummy" user to
> get into this situation, so a generic solution is more urgent now.

Exactly. All we are talking about are these "dummy" users which have to 
be stopped from doing something stupid. If we make it too simple for 
the users to shoot themselves in the foot they will eventually do it. 
And it will be partly your fault if they do so.

> even when i implement this safeguard in kdm, the user will still be
> able to nuke himself _in that way_ (you know that many work as root
> or have setuid root shutdown-utils).

This is _no_ valid argument. We have to make Unix more secure and not 
less secure by adding new traps. But I'm repeating myself.

> the bottom line is, that i don't consider this inherent problem of
> multi-user architectures a show-stopper for "my" feature. i can (and
> will) make the situation better (by safeguarding the most prominent
> place to shut down), but i simply can't fix it to 100%. so this
> problem cannot be considered a show-stopper, as in the end it would
> mean to remove any multi-user capabilities from unix for the sake of
> user's safety.

You are exaggerating. All we ask from you is to make it as hard as 
possible for newbies to do something stupid. If you can't do this for 
KDE 3.1 then please postpone your nice feature until KDE 3.2. Many 
other and much more important features have been postponed with every 
new release of KDE. I don't see why you should be allowed to violate 
the feature freeze by committing an incomplete feature.

Regards,
Ingo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQE9p0yoGnR+RTDgudgRAqXQAJwNqA/2eP+KshZu07D9jcO5Zvg/4wCeIkFD
ZN3ciUZIwWe3AguHvZl8tV8=
=Elko
-----END PGP SIGNATURE-----