One reason for Unix's permission checking timing

May 17, 2009

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.)

Written on 17 May 2009.
« The crucial difference between online and offline backups
Some notes on rewrites in Apache .htaccess files »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun May 17 23:30:01 2009
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.