[12143] in bugtraq
Re: Fix for ssh-1.2.27 symlink/bind problem
daemon@ATHENA.MIT.EDU (Casper Dik)
Wed Oct 6 14:49:40 1999
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id: <199910060906.LAA10569@romulus>
Date: Wed, 6 Oct 1999 11:06:07 +0200
Reply-To: Casper Dik <casper@HOLLAND.SUN.COM>
From: Casper Dik <casper@HOLLAND.SUN.COM>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: Your message of "Mon, 04 Oct 1999 20:04:53 EDT."
<m33dvqk6ze.fsf@sgifford.tir.com>
> It has always been my understanding of UNIX sockets that they need
>not appear in the filesystem at all; whether inodes and directory
>entries are allocated for them is an implementation detail. The only
>guarantee is that if one process is listen()ing on a socket, and
>another process connect()s to a socket with the same path, they will
>be talking to each other.
Yes, that's in the 4.2 BSD manuals.
> If this is not the desired behavior, at least a mechanism needs to
>be provided which can instruct the kernel not to follow symlinks (like
>the O_EXCL or O_NOFOLLOW flags passed to open(2) on BSD or Linux) when
>binding to a UNIX domain socket.
It would be interesting to make a comparison between the various flavours
of Unix and the various system calls that create non files to see whether
they follow symlinks or not.
On Solaris, only open(O_CREAT) (w/o O_EXCL) and creat() do so;
the following do not follow symbolic links as the last component of
the pathname:
mknod (making pipes or devices)
mkdir
bind
(others?)
(doors are created as files followed by fattach, so the
user has control)
Casper
