Mail Archives: opendos/1997/08/28/23:49:34
> From ark AT mpak DOT convey DOT ru Fri Aug 29 13:29:23 1997
> nuqneH,
> > I've been looking at the linux code for accessing (v)fat dos
> > partitions; until long filenames (and the extra time information that
> > came at the same time), it was relatively easy to modify Linux to
> > support permissions flags, groups ID's,m and user ID's (and, sort of,
> > passwords) in a way that is compatible with OpenDOS (well, really
> > Multiuser DRDOS).
>
> Caldera seems to have no intention to release Multiuser DOS.
> They do not even talk about it and they ignore any questions about
> Concurrent DOS product family. :(
> Too bad.
More info...
DRDOS 6 had the call: int21h, AX=4307 to set the file's owner. I don't
suppose much software used this, although it is useful. Moreover,
there seems to be a couple of bytes next to the user id field in the
DRDOS/OpenDOS directory entry for the group id, but no system call to
use it. Both these fields, along with the encrypted password field,
conflict with Win95's use of these previously unused bytes in each
directory entry. The permissions flags are stored in a word that is
unused by Win95.
We don't have to be DR Multiuser DOS to make use of them; in fact some
playing around with the use of these bytes is essential simply to avoid
OpenDOS refusing to work with some files on disks created under Win95.
But since Digital Research carefully maintained compatibility all the
way through many versions of DRDOS, Multiuser DOS, FlexOS, etc then it
makes sense to try hard to ensure any changes are as compatibile as
possible with everything else.
I am interested both in using the protection OpenDOS gives to make PC's
I set up a bit more secure from fiddling and such like, and in getting
around some annoying problems in Linux when accessing DOS partitions.
As OpenDOS stands, it has 16 bits for read, write, execute and delete
permissions for the owner, the group and the world (plus 3 or 4 bits
left over), however DRDOS (since the multiuser code was removed)
basically duplicates the owner's 4 bits into the other two blocks of 4
bits. OpenDOS could have the AX=4306 & 7 calls reinstated, and calls
like these improved to not only support group id's but to not get
confused when these fields have been written by incompatible software
(win95 isn't the only one).
As it stands, if the group id field is non-zero it is a safe bet that
the directory entry has been written by Win95 (or one of the non-DOS
diskette writing programs I've seen that put spaces in these bytes).
So the password and user id should be ignored.
Alternative ways of detecting Win95 changes to the directory entry exist,
and I guess the best method is to use a mixture of tests.
Ultimately, though, I'd like to see a new filesystem for OpenDOS (no
reason why the same system calls cannot be used, of course), and for
FAT directory entries the most compatible (all-round) solution might be
to have...
OFFSET PRESENT OPENDOS WIN 95 USE PROPOSED NEW STANDARD
====== =============== =========== =====================
00-0B ----------------name,ext,attr------- (no change here)
0C dunno reserved (case?) (no change)
0D dunno creation 10ms creation time in 10ms
0E-0F encrypted password creation time zero
10-11 group (GID)? creation date creation date
12-13 owner (UID) last access date last access date
14-15 permissions flags reserved (zero) permissions flags
16-1F ------------date/time of last write, starting cluster ---
Notes: Creation time set to zero isn't too much of a problem - this avoids
false password reaction in older versions of OpenDOS, Novell DOS, DRDOS;
knowing the creation date is usually enough, software should know how
to handle a zero creation time since MSDOS 6 (etc) will set it to zero.
The most important change is that passwords, user id numbers, and potentially
other information will be stored outside the directory entry, in a single
file per directory for all files that need access control in that directory.
If the file is restricted from reading it can be scrambled somehow, meaning
normal directory backup routines, network access, etc can still work, but
the data remains private. Otherwise the file is stored normally, and can
be read as normal via old DOSes but not deleted (any more easily than under
the old system). Password-protected files created under DRDOS can be used
with this system; diskettes with protected files created under this system
will be recognised as protected under DRDOS etc but the password won't be
the same (it will be easy for somebody that knows what they're doing to
delete such files, but the read-protected ones will be safer from snooping
than before).
Other advantages: it makes the transition to a new filesystem (e.g.
ext2fs, or something totally new) much easier, and it increases overall
security while increasing compatibility.
-------------------------------------------------------------------------------
Mark Aitchison, Physics & Astronomy \_ Phone : +64 3 3642-947 a.h. 3371-225
University of Canterbury, </ Fax : +64 3 3642-469 or 3642-999
Christchurch, New Zealand. /) E-mail: phys169 AT csc DOT canterbury DOT ac DOT nz
#include <disclaimer.std> (/' Callsign: ZL3TQE
-------------------------------------------------------------------------------
- Raw text -