lkml.org 
[lkml]   [1997]   [Dec]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: PATCH against 2.1.72: better symlinks for a better future (was Re: security warning)
From
Date
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>

\
 
 \ /
  Last update: 2005-03-22 13:40    [W:1.404 / U:0.304 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site