Date: Tue, 9 May 95 16:14:48 MDT From: terry@cs.weber.edu (Terry Lambert) To: Bernard.Steiner@Germany.EU.net Cc: freebsd-bugs@FreeBSD.org Subject: Re: strange symlinks Message-ID: <9505092214.AA19830@cs.weber.edu> In-Reply-To: <199505092047.WAA17816@qwerty.Germany.EU.net> from "Bernard.Steiner@Germany.EU.net" at May 9, 95 10:47:40 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Assumption: directory /tmp exits, owned by bin.bin mode 1777
> then ln -s /tmp/foo /tmp/bar produces symlink /tmp/bar *owned* by bin
> regardless of who issued the symlink command, and subsequent rm /tmp/bar
> is refused for non-owner, i.e. any normal user except for bin and root.
>
> This is bogus.
It's a generic 4.4 problem with making symlinks in the directory entries
themselves. Probably when the sticky bit is set, it ought to make the
old-style links instead.
> The next one may be a general 4.4 problem...
> assumption: /tmp/foo does not exist, /tmp/bar is a symlink to /tmp/foo.
> chdir("/tmp/bar") fails with ENOENT, but at the same time
> mkdir("/tmp/bar", 0x777) fails with EEXIST.
I think this is a generic result of the path component item evaluation
order. I guess the only thing to say is that "according to the code,
this is correct behaviour" 8-).
> Third, whatever happened to the fchdir() syscall that I vaguely remember
> having had in (at least) 386BSD0.1 ?
It had *better* still be there! I've been using it with a couple of
minor code changes to get about a 15% performance increase out of
Samba by keeping an open descriptor for the exported file system to
make all opens relative instead of having to traverse every component
up to the path on the volume itself.
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9505092214.AA19830>