[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] Security again
> > Which is quite unfortunate, when we come across a problem of a choice
> > between compatibility with the single-user, single-tasking DR-DOS (TOS)
> > and the features expected from a multiuser, multitasking MiNT.
>
> OK, so we have the choice between making MiNT a bit more secure from attacks
> but killing many popular TSRs, and keeping compatibility at the cost of
> risking an attack which will almost certainly never occur. Tough question... ;-)
Hehehe, well, actually, the latest posting (mine) was written when I had
quite something else in mind than the private Cookie Jar stuff and a fix
against crashing the OS using the method I posted some time ago. My
mistake I didn't tell you about this generalization, but it was about
fixing possible workarounds for the user limits the system imposes, rather
than about preventing system crashes in a (costly) way.
So, better late, than never: I do understand that the proposition I made
about making Cookie Jar private for processes may cause compatibility
problems and there must be invented something else (if anything can be
invented, but I guess so, there are no unsolveable problems, the question
is only the price of the solution). Now we make the Cookie Jar mode off
:-) in this discuss (and I promise I'll come up some day with something
else to fix that thing :-)).
> > For example, which one is such a program (except N.AES, which is
> > F_OS_SPECIAL and does not count here).
>
> DHST-servers announce their presence with a cookie. To do this they must
> ofcourse be able to create a cookie that's available for others and they
> must also be able to remove it when they terminate. And then you have the
> slightly popular BubbleGEM and the BubbleHelp server... Stic also use a
> cookie IIRC.
Well, I can perfectly and happily live without BubbleGEM (I 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),
however, I could hardly live without your Taskbar, which is DHST server.
Nevertheless, I think there should be an alternative way to communicate
with such a program (DHST server), other way than the cookie jar, so what
about talking to the author of the DHST protocol about an expansion?
> I don't like the cookie-jar implementation myself, but it's a fact that many
> does (or don't care). Some people even puts pointers to data and code in
> applications in their cookies, apparently without thinking about what happens
> when some client calls code in an application which doesn't exist anymore...
> Two horrible examples of this is Stic and Keywatch.
Well... in such a case solution is easy ------> trashcan. And seriously,
there is a need for a decent programming doc for MiNT, to avoid a
situation, that some programming technique is not valid and has a cleaner
replacement, but software developers answer: "But Atari documentation
dated 14. July 1415 AD says, that..."
Such a doc could split system functions into classes like:
- supported and encouraged to use
- supported for TOS compatibility
- supported, but strongly discouraged
- not supported anymore
I don't know though...
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.