== One reason for Unix's permission checking timing Unix has a slightly odd way of handling file access permissions, in that they're only checked when a file is opened, not every time that you attempt to do something with the file handle. While the choice is defensible, in many ways checking permissions on access would be more convenient, since it would enable things like immediately revoking access to files, and very few programs actually care about this. (And these days, it would fit better into network filesystems, many of which operate this way anyways.) Having said that, one reason that Unix as it currently stands pretty much has to have this approach is the issue of how terminals interact with setuid programs. Since your terminal is not accessible to other UIDs (except to root as a special case), a 'check on every access' environment would need some special mechanism so that a setuid program would still be able to print output and get input. This would also apply to any redirection that you wanted to do with setuid programs, which expands the problem even more. (Current Unix systems actually have to have a workaround for network filesystems due to this. I believe that basically all of them save the UID and so on in effect when a file was opened with the kernel filehandle, and then the network filesystems carefully send that set of identification to the server, not the current process's current UID et al.) (Disclaimer: I doubt that this issue is the reason Unix made this choice; it's more something that comes up once you've made the choice and designed your system accordingly.)