9. DOS permissions

Whilst planning your network, don't forget about what the inside of each machine looks like. If people share machines you need to control how much access they have to remote files, or even local files.

9.1 /dos/c
9.2 Access
9.3 My Configs
9.4 My Configs - why
9.5 Mount Control
9.6 Group Control
9.7 The really simple way
9.8 Other Limitations
9.9 Don't do it

9.1

/dos/c

If your workstation is a dual-boot DOS or Linux machine, you want to make the DOS files available in both modes. Linux can do this by default (unless you exclude the driver from the kernel and modules list), but you do have to as Linux to do so.

The files get mounted under /dos/c (that leaves /dos/d for another partition, and /dos/a for the diskette). Doing this will have implications to the user and other users (ie they can / can't access files).

9.2

Access

Every UNIX file has an owner, a group and access permissions. These are held in the file's inode along with other information.

DOS doesn't have these, so when an msdos disk partition is mounted under Linux, the code has to fake them (as well as converting the DOS file-modification-time to UNIX mtime format).

The result, is that every file (and dir) on the DOS partition appears to belong to a specific user, and one specific group. As the sys-admin, you can edit /etc/fstab to specify who that user and group is, as well as specifying the chmod 640 permissions (the user-group-other read-write-execute permissions, written in octal as used by the chmod command).

When planning your workstation, you need to consider the implication of ANY user on the machine (and possibly the network), getting access to your confidential files. Seen the other way around, the owner of the files wants to get access.

Your key control, is the mount command, and it's configuration in the /etc/fstab file. Here you specify the uid,gid and umask settings. They are explained in the man pages for mount(8).

9.3

My Configs

Here is the relevent line from my /etc/fstab file, and what it makes my system look like. Here it is split one-field per line, in /etc/fstab it is one long line.

# all one line
/dev/hdb3
/dos/c
msdos
defaults,user,umask=027,uid=1016,gid=11,noexec,noauto
0
2
Splitting that long field up gives:
defaults	# other defaults
user		# user can mount
umask=027	# as though chmod 750
uid=1016	# all files owned by gps
gid=11		# group floppy
noexec		# dirs=750 files=600
noauto		# do not mount on boot

When I do ls -l /dos/c I get something like:

-rw-r-----   1 gps      floppy        396 May 28  1995 autoexec.bak
-rw-r-----   1 gps      floppy      47845 Apr  9  1991 command.com
-rw-r-----   1 gps      floppy        474 Jan 17  1996 config.sys
-r--r-----   1 gps      floppy      37394 Apr  9  1991 msdos.sys
-r--r-----   1 gps      floppy      33430 Apr  9  1991 io.sys
drwxr-x---   8 gps      floppy       8192 Jan 30  1995 windows
drwxr-x---   2 gps      floppy       4096 Jan 29  1995 dos5
drwxr-x---   3 gps      floppy       4096 Jun 19  1995 etc
drwxr-x---   3 gps      floppy       4096 Jul 22 14:50 gps

9.4

My Configs - why

All the files are owned by the "gps" user. That is because this is my workstation.

I put all the files into the "floppy" group, to reduce supprises when I use the floppy disk, but you might not want to do that, as people who have permission to use the floppy drive (for their own files), shouldn't also get access to my files.

I don't allow others read, because I am not aware of any need to, and there are probably confidential files down there. If only I had the time to go through them all and re-organise my files!

The noexec option, prevents the direct execution of any shell scripts or binaries, from that partition. Otherwise, every file has the 'x' bit set, and midnight commander tries to run them when I accidently press the Return key.

9.5

Mount Control

The user option allows any user to mount that partition, provided you haven't removed the suid bit from mount (which I have done).

The noauto option means that the partition isn't mounted at boot time. I know which days I actually used that data, and the full list isn't advertised in the locate-db. It also means that the backup script has to do something extra.

Personally, I am drifting towards only allowing certain operations as root (such as mount). This is easy for me, because I have a root console available. If you don't want users to have the root password, you can explore the user option, or sudo or write an SUID wrapper like dial_ppp that control's who can do it, and what options gets used.

9.6

Group Control

You can create a group (gpsdosc) and add any number of users to that group, by editing the /etc/group file. EG To allow the the apache web server, read access, you can either give every file chmod 644, or add the apache server to the group. Hopefully apache will only broadcast files that you specifically allow, but apache is liberal about following symbolic links, so be careful (or don't do it this way).

If you want group write permission, you will get it for every file on that partition, ditto for "other-users" read permission.

9.7

The really simple way

	chown gps /dos
	chgrp mygroup /dos
	chmod 750 /dos

Since other users can't get past the /dos/. directory, they can't reach /dos/c. However, you still have problems with read and write permissions, for those who can. This also depends on the interpretation of directory permissions. SVR4 allows access even when the directory is unreadable and unserachable, if you can 'guess' the filename.

Whatever method you choose, pick a few sample users and check it.

9.8

Other Limitations

Remember also that MSDOS file partitions, use 8.3 names: filename.ext Attempting to create longer names (eg filename.ext-old) might get truncated, possibly overwriting other files!

WIN-95 uses long names, via a trick. If you want this, you should read up on vfat and msdos filesystem drivers. If you really must have unix like permissions for your DOS files, you can use umsdos.

Also, unix records when a file was last read (accessed) as well as written. The virtual file-system code (which makes the DOS FAT filesystem look like a unix filesystem), simply forgets about the atime and only maintains the mtime.

9.9

Don't do it

The DOS filesystem works a charm. I use it to access all my legacy files, even from dosemu!

It is particularly valuable, because Linux can use DOS partitions, but DOS can't read Linux partitions (there is a utility, but not one that you would plan to use). EG to pre-install DOS files downloaded from the net (eg tcl/tk), or to read DOS data files with awk.

However, you don't actually plan to use the DOS filesystem, for anything other than occasional access. If you allow apache access, it is only whilst you get something better sorted. When running a Linux system, use proper Linux files.

You might plan to use swap files, on the DOS partition, where you have the space available, and the disk is otherwise idle. You can easily delete and recreate them if needed.

If your requirements are more advanced (eg several different users across the network), you should consider serving files to the DOS machines from a unix server, using SAMBA. Then every client PC uses it's own login to access it's files.