Messages in this thread | | | Subject | Re: PATCH against 2.1.72: better symlinks for a better future (was Re: security warning) | From | (Kevin Buhr) | Date | 17 Dec 1997 08:32:15 -0600 |
| |
Oh, one more name-resolution pecularity should be noted...
In 2.1.xxx, a "lookup_dentry" call with "follow_link==0" will still follow a final link if the pathname has trailing slashes. That is:
touch foo ln -s foo foo-symlink perl -e 'rename "foo-symlink", "bar-symlink"' # moves the symlink perl -e 'rename "bar-symlink/", "bar"' # moves the underlying file
(Once again, GNU's "mv" does some hanky-panky that confuses the issue.)
IMO, this is a great feature. It let's us explicitly override the "do not follow symlinks" semantics of any desired system call. And, if the GNU utilities didn't so often get in the way, it would give the end-user the same option. On the other hand, I assume it's nonstandard, and it's a little disconcerting that (1) the technique works on nondirectories instead of returning ENOTDIR or something; (2) an "lstat" on "foo/" stats the underlying file; (3) possibly other strangenesses I haven't thought of.
2.0.xxx does all sorts of weird things with trailing backslashes. I don't have source handy, but it seems that "open" returns ENOTDIR, and "rename"---for the source argument---returns ENOENT even when both symlink and underlying file existed.
Kevin <buhr@stat.wisc.edu>
| |