Date: Fri, 29 Aug 1997 15:45:35 +1200 From: physmsa AT cantua DOT canterbury DOT ac DOT nz (Mr M S Aitchison) Subject: Re: Linux fat support with OpenDOS extensions? To: caldera-opendos AT caldera DOT com, opendos AT delorie DOT com Message-id: <199708290345.PAA07422@cantua.canterbury.ac.nz> Precedence: bulk > 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, (/' Callsign: ZL3TQE -------------------------------------------------------------------------------