RE: [MiNT] Security again

["Konrad M. Kokoszkiewicz" <draco@obta.uw.edu.pl>]

> I'd say that real solution would be to protect the kernel itself, but IIRC
> this is not trivial :-( I'd really like to see some clever mind coming up
> with a solution for this.

Well, when memory protection is on, the whole kernel is protected. Except
the Cookie Jar. And besides, ruining the cookie jar does not have
immediate influence on all the running stuff, but obviously can create
problems when starting new programs (even MiNT Lib uses the Jar to know if
it is running on MiNT). We'll probably leave it as is until some genius
comes and fixes that, as you said.
 
> > Well, I can perfectly and happily live without BubbleGEM (I 
> 
> Me too, it's a nice concept but heavily overused (by me as well, I admit
> it). Those nasty bubbles pops up everywhere. But most people like it, it
> looks good on screenshots ;-)

Yes, indeed :-) Anyway, problems with BubbleGEM can be created either by
bugs in the BubbleGEM or in the AES, but since many programs need AES and
noone really needs BublbeGEM, the choice is obvious.

> > kicked it out
> > awhile ago because it seemed it causes some problems with 
> > GEM, and really,
> > the problems have gone away after I put the BGEM to the trahscan),
> 
> I know, the implementation is not as good as it could have been. I wrote a
> windowed replacement myself, but it turned out even worse than the original
> :-)

Hum, in what way "worse"? By the way, don't you think that the AES lacks
some class of windows? E.g. such one, which, when open, wouldn't put
currently topped window to bottom and simultaneously wouldn't block the
screen. Something like a nonblocking dialog box (but not a "windowed"
dialog, because this is in fact a normal window). This could be useful for
things like BubbleGEM or nonblocking menus.

> > Nevertheless, I think there should be an alternative way to 
> > communicate
> > with such a program (DHST server), other way than the cookie 
> 
> Definitely, but who will use it?

You.

> DHST-servers only puts their APID in the
> cookie, a much cleaner way to announce it's presence would simply be to use
> menu_register(-1, "DHSTnnnn"), where "nnnn" is a unique string (e.g. "TSKB"
> or "_SMU").

Or use similar techinque as with AV server (env string DHSTSERVER=BLURP,
then you can retrieve its apid the normal way).
 
> > jar, so what
> > about talking to the author of the DHST protocol about an expansion?
> 
> I don't think Thomas Much develops TOS-software anymore.

So someone else should expand the protocol (before Magic developers will
put their hands on it to invent something that breaks every known Atari
standard).

> b) ...MagiC's memory-protection can not catch things like e.g. Keywatch
> calling user-installed functions in crashed/killed processes. Hmm, bad
> example, MiNT can't either... But atleast MiNT doesn't commit suicide if
> Stic crashes with running clients.

MagiC has memory protection? Where? :-)
 
> I think the solution must be to make these developers aware of what they're
> doing. For some strange reason many of them think that the real problem is
> MiNT's memory-protection and *not* their implementation!

The point is that most difficult thing is to "make" someone "do" something
without using a type of fascism :-)

Gtx,

--
Konrad M.Kokoszkiewicz
|mail: draco@atari.org                  |  Atari Falcon030 user   |
|http://www.obta.uw.edu.pl/~draco/      | Moderator gregis LATINE |
|http://draco.atari.org                 |       (loquentium)      |

** Ea natura multitudinis est,
** aut servit humiliter, aut superbe dominatur (Liv. XXIV,25)
*************************************************************
** U pospolstwa normalne jest, ze albo sluzy ono unizenie,
** albo bezczelnie sie panoszy.