Wandering Thoughts archives

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

An inexplicable omission in bash's sourcing of .bashrc

I discovered recently that I missed a case in my writeup of when bash sources your .bashrc, or technically I didn't miss a case because bash has an inexplicable omission: bash doesn't source your .bashrc when you ssh in with a pty. That is, if you do:

ssh -t host command ...

Your .bashrc is not sourced. Neither does bash source your .login (well, of course).

This was an unpleasant surprise when I found it out recently, since on some of our systems we use ssh to do things that we want to interact with, and they involve commands that are not on the default $PATH. Up until recently I was counting on .bashrc to fix up that problem, which is how I came to discover the issue. (There's nothing like actually trying your plans out.)

I assume that this is caused by a misfire in the bash heuristics that try to figure out if you are ssh'ing in. Hopefully this means that it will be fixed in the future (although some of the systems affected by this are Solaris machines, which are unlikely to get new versions of bash any time soon).

(Although it might be tempting to see this as an argument against such heuristics in general, I don't agree with that position. For better or worse, bash's heuristics to source .bashrc when you ssh in give you generally useful behavior. And taking away features entirely just because they can't be implemented perfectly is not generally very helpful.)