Windows file model

The Windows operating system supports a variety of legacy filesystems for back-ward compatibility with DOS and Windows 9x. These older filesystems are insecure, in the sense that they have no mechanisms for restricting access to files. The filesystem NTFS was introduced with NT in order to solve this problem.

The filesystem has gone through a number of revisions and no doubt will go through many more before it reaches constancy.

NTFS, like the Unix file system, is a hierarchical file system with files and directories. Each file or directory has an owner, but no group membership. Files do not have a set of default permission bits, as does Unix; instead they all have full-blooded ACLs, which assign a set of permission bits to a specific user. NTFS ACLs are similar to other access control list models, in filesystems such as the AFS and DCE/DFS. They have all of the flexibility and all of the confusions which accompany ACLs, such as inheritance of attributes from parent directories and creation masks. The NTFS file system is indexed by a master file table, which serves an analogous function to Unix’s inodes, though the details are somewhat different.

Filesystem layout

Drawing on its DOS legacy, Windows treats different disk partitions as independent floppy disks, labelled by a letter of the alphabet:

A: B: C: D: ...

For historical reasons, drive A: is normally the diskette station, while drive C:

is the primary hard disk partition. Other drive names are assigned at random, but often H:is reserved for partitions containing users’ home directories. Unlike Unix, different devices are not sewn seamlessly into a unified file tree, though this will probably change in a future release of Windows. Originally, DOS chose to deviate from its Unix heritage by changing the subdirectory separator from / to \. Moreover, since each device is treated as a separate entity, there is a root directory on every disk partition:

A: B: C: ...

and one has a notion ofcurrent working drive, as well ascurrent working directory.

These distinctions often cause confusion amongst users who work with both Unix and Windows.

The layout of the Windows filesystem has changed through the different ver-sions, in an effort to improve the structure. This description relates to NT 4.0.

The system root is usually stored inC:\WinNTand is generally referred to by the system environment variable%SystemRoot%.

• C:\I386 This directory contains binary code and data for the Windows operating system. This should normally be left alone.

• C:\Program Files This is Windows’s official location for new software.

Program packages which you buy should install themselves in subdirectories of this directory. More often than not they choose their own locations, however, often with a distressing lack of discipline.

• C:\TempTemporary scratch space, like Unix’s /tmp.

• C:\WinNTThis is the root directory for the Windows system. This is mainly for operating system files, so you should not place new files under this directory yourself unless you really know what you are doing. Some software packages might install themselves here.

• C:\WinNT\config Configuration information for programs. These are gen-erally binary files so the contents of Windows configuration files is not very interesting.

• C:\WinNT\system32 This is the so-called system root. This is where most system applications and data-files are kept.

File extensions

Whereas files can go by any name in Unix, Microsoft operating systems have always used the concept of file extensions to identify special file types. For example:

file.EXE An executable program file.DOC Word document

file.JPG Graphic file format

Links and shortcuts

Like Unix, Windows also has ways of aliasing files in the filesystem. Windows has hard links, or duplicate entries in the master file table, allowing one to associate several names with a given file. This is not a pointer to a file, but an alternative entry point to the same file. Although the filesystem structure of NTFS is different from the Unix filesystem, the idea is the same. Hard links are created from the POSIX compatibility subsystem, using the traditional Unix command nameln. As with Unix, hard links can only be made to files on the same disk partition. Most users will not use these hard links, however.

Windows also has short cuts. A short cut is a small file which contains the name of another file, like a short script. It is normally used for aliasing scripts or programs. Unlike Unix’s symbolic links, short cuts are not handled transparently by the operating system, they are actual files which can be opened with a text editor. They must be read and dealt with at the application level. Short cuts can be given any name, but they always have the file extension .LNK. This suffix is not visible in the graphical user interface. They are created from the graphical user interface by right-clicking on the item one wishes to obtain a pointer to.

Unix compatibility packages like Cygwin32 use short cuts to emulate symbolic links. However, since short cuts work at the application level, what one package does with a short cut is not guaranteed to apply to other software, so the usefulness of short cuts is limited.

Access control lists

Windows files and directories have the following attributes. Access control lists are composed of access control entries (ACEs) which consist of these.

Permission bit Files Directories

R(Read) See file contents See directory contents W(Write) Modify file contents Modify directory contents X(Execute) Executable program Cancdto directory

D(Delete) Deletable Deletable

P(Permission) Permissions changeable Permissions changeable O(Ownership) Ownership changeable Ownership changeable

The read, write and execute flags have the same functions as their counterparts in Unix. The execute flag is always set on .EXE files. The additional flags allow configurable behavior, where behavior is standardized in Unix. The delete flag determines whether or not a particular user has permission to delete an object (note that a user which has write access to the file can destroy its contents inde-pendently of this). The permission and ownership flags likewise determine whether or not a specified user can take ownership or modify the permissions on a file.

Access control lists, or Access control entries are set and checked with either the Windows Explorer program (File/Properties/Security/Permissions menu) or the caclscommand. This command works in more or less the same way as the POSIXsetfaclcommand, but with different switches. The switches are

/G Grant access to user.

/E Edit ACE instead of replacing.

/T Act on all files and subdirectories.

/R Revoke (remove) access rights to a user.

/D Deny access rights to a given user.

For example:

hybrid> CACLS testfile

C:\home\mark\testfile BUILTIN\Administrators:F Everyone:C

MT AUTHORITY\SYSTEM:F hybrid> CACLS testfile /G ds:F

Are you sure(Y/N)?

hybrid> CACLS testfile

C:\home\mark\testfile HYBRID\ds:F

In this example the original ACL consisted of three entries. We then replace it with a single entry for userdson the local machine HYBRID, granting full rights.

The result is shown in the last line. If, instead of replacing the ACE, we want to supplement it, we write

hybrid> CACLS testfile /E /G mark:R {\var wait for 30 seconds}

Are you sure(Y/N)?

hybrid> CACLS testfile

C:\home\mark\testfile HYBRID\ds:F HYBRID\mark:R

New files: inheritance

Although the technical details of the NTFS and its masking schemes are not well documented, we can note a few things about the inheritance of permissions. In the absence of any ACL settings on a parent directory, a new file is created, granting all rights to all users. If the parent directory has an ACL, then a new file inherits that ACL at the time of its creation. When a file is moved, it keeps its NTFS permissions, but when a file is copied, the copy behaves like a new file, inheriting the attributes of its new location.