Cookie jar patch for Supexec/Super patch?

[Evan Langlois <ekl@dhc.net>]

Hartmut Keller wrote:

> >>>>> ""Konrad" == "Konrad M Kokoszkiewicz" <draco@mi.com.pl> writes:
>
> > OK, what about another way: implement a system call allowing to access
> > (to read) vital GEMDOS variables, like p_cookie or hz_200, from any user
> > process and prepare a whole MiNT distribution (like KGMD is) supporting
> > it?
>
> That's more or less what I was talking about all the time. But I think
> we should have an own system call for each variable. Otherwise we get
> problems with the return types (one is long, one is short, one is
> pointer, one is time_t, etc.). This is also less vulnerable to changes
> in the future. Probably we can group some variables that belong
> together somehow.

I originally proposed a system call that would read a cookie, set a cookie,
destroy a cookie, and get a list of cookies - this call would also read the
hz_200 variable, and a few others as if they were cookies.  The cookies were
pointed to by the regular cookie jar pointer, for backwards compatibility, but
the OS would take care of expanding the jar and returning the values so that
no supervisor access would be needed - due to some bugs I never fixed in
reallocating the jar the code was either #ifdef 'd  out or completely removed.

Obviously, the mintlib would have to modified to take advantage of this, and
programs would have to be recompiled to run on any systems that were made
secure.   I think super() and supexec() should also be made root only once a
migration path is available.