readonly files

[ekl@sdf.lonestar.org (Evan K. Langlois)]

========================================================================
 Hmmm, wrong. MiNT (or the denyaccess() routine) does very well allow root
to open a readonly file for writing. The problem is that you must ignore the
reported filemode and just try it. Most programs seems to self-check the
file modes before trying to open the file, and therefore fail. I've seen
some GNU tools and editors doing this.
========================================================================
 
Nope, it's checked after denyacess is called I think.  There is an extra
check for it, anyway, dosfile.c.   I quote :
 
/*
 * an extra check for write access -- even the superuser shouldn't
 * write to files with the FA_RDONLY attribute bit set (unless,
 * we just created the file, or unless the file is on the proc
 * file system and hence FA_RDONLY has a different meaning)
 */


========================================================================
> IMHO, the biggest problem of MiNT is its compatibility with TOS.

 :-)
========================================================================
 
No, TOS compatibility is MiNTs biggest asset.  Without it, MiNT is nothing.
There are no super-apps for MiNT, and as a Unix, it falls short.  Lets
face it, MiNT can't compete with any workstation version of Unix around,
and its NOT because of TOS compatibility!   MiNT isn't gonna compete with
a SUN or a NeXT.  If you want a real Unix, then get one!!  Mach is availble
for FTP - get it, port it, and when your done, write a TOS server to run
old St apps.
 
MiNT's biggest plus is that you can run those TOS apps that people bought
an ST to run, like Pagestream, MIDI programs (well, a few will run under 
MiNT), and similar programs.  People aren't gonna shell out big money on
ATARI harware (ATARI hardware =IS= overpriced) just to run MiNT on a text
screen with no GEM, no port of X, nothing,  It won't happen.  Therefore,
be as TOS compatibile as possible in the kernel, and when that conflicts
with the needs of POSIX, ajust the library to compensate - either that or
create a new domain.
 
Here's my guidline for a new domain :

Domain X : 
  No XBIOS or BIOS access except by the super-user.  No VDI or AES access
except by the super-user.  Pdomain() cannot change to TOS or MiNT domain (but
maybe others).  Remove calls Fsfirst/Fsnext, Dsetdrv/Dgetdrv, Dgetpath (use
Dgetcwd).  All paths are relative to drive U: - cannot change drives.  All
the XBIOS and BIOS functions that alter memory blocks (Getmpb, etc) or do
direct disk access (Getbpb, Drvmap, Rwabs) and the interrupt control 
functions (Setexec, etc) are removed - not even Super-user can use them.
Bconin/Bconout stuff may be used by super-user and XBIOS sound stuff may
be used by super-user.   Also, domain is inherited by children of this 
domain.  All OS calls work as POSIX as possible.

MiNT domain :
  VDI+AES+XBIOS are restricted to super-user.  All other functions are
as-is (unless buggy!), except Super(), Supexec(), Rwabs(), Setexec(), etc,
(the dangerous ones) are restricted to super-user.   Otherwise, this is
MiNT domain.

TOS domain :
  Totally 100% TOS compatible, other than the fact that you can get access
to pipes, and multitask and such.


By making init a domain 3 process, remote users are restricted.  Most apps
should function in the MiNT domain (GEM stuff).  Unix utils would function
in domain 3 (maybe a new executable format that automatically starts app
in domain 3, compatible with a.out format??)

Anyway .. it's just a thought .. it could save us from the TOS vs. Unix
battles.  After all, that is what Pdomain is for!!


CYA
Evan K. Langlois
ekl@sdf.lonestar.org

PS: even if the offical version of MiNT won't support this 3rd domain, you
could begin hacking up a the domain anyway - things like not returning EPTHNF
for ENOENT or whatever would differ between domain X and MiNT domain, and
TOS domain would be EPTHNF + always 8+3 upper-case, etc.


l