UNIX solves this problem by allowing per-file permissions rather than just the home files license permission described.

The file (SYSX)BILL could be given write permission by the account which owns the compiler, which would be run in setuid mode so that it had that account's permissions. This would ensure that no other files in the (SYSX) directory would be threatened by misbehavior of the compiler.

The compiler already knows the name (SYSX)BILL because that its where it is writing its billing information. So there is no difficulty in building an output-checking routine which makes sure that files being opened in other modes do not match the name of this file.

From the article by Norm Hardy: 

The code to deposit the debugging output in the file named by the user
cannot be blamed. Must the compiler check to see if the output file
name is in another directory by scanning the file name? No--it is
useful to specify the name of a file in another directory to receive
output.

With per-file access controls, the issue is not what directory the output is in, but whether the output file matches the name of one of the reserved files. 

Should the compiler check for directory name SYSX? No--the
name "SYSX" had not been invented when this code was written. Indeed
there might be a legitimate request for the compiler to deposit its
output in some file in SYSX made by someone with legitimate access to
that directory.

The compiler must know the name of the billing file if it is going to open it for output. So it should be possible to check for whether user files are matching the name of that file. 

Should the compiler check for the name (SYSX)BILL? That
is not the only sensitive file in SYSX. Must the compiler be modified
whenever new files are added to SYSX?

With per-file access controls, no updating is needed except for when the compiler is changed. With proper design, the compiler can have a list of sensitive files, and when new ones are added to the list (due to revisions to the compiler) it can automatically check for them when it opens user output files.

Access control systems are not a panacea, but in the specific case described here they don't do all that badly. The main problem seems to be that the operating system could only restrict access on a per directory basis. Providing per file access controls makes the problem much more manageable.

Hal Finney
March 17, 1998