Eivind Eklund <eivindat_private> writes: > On Sat, Oct 02, 1999 at 06:38:46PM -0400, Scott Gifford wrote: > > I've put together a patch that lets ssh work around the OS bug that > > allows bind to follow symlinks. > > There isn't general consensus that this is an OS bug. We (as in > FreeBSD) have installed a workaround consisting of blocking symlink > following for the case, but we have not yet decided if we should make > this permanent. 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. This understanding comes in part from Richard Stevens talks and books, including "Unix Network programming", which states "The 4.3BSD implementation creates a file in the filesystem with the specified pathname, although there are comments in the 4.3BSD manuals indicating that future versions might not create these files." [1] From this assumption, it follows that a user program shouldn't have to use filesystem operations to bind() to a UNIX domain socket. 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. I don't think it is reasonable to expect user programs to jump through this many hoops (in my SSH patch, I had to make a temporary directory, stat the directory, chdir() into it, stat my current directory, bind() the socket, rename the socket, chdir() back out of my temp directory, and rmdir() the directory --- 8 additional steps, and over 60 additional lines of C code) to avoid this. Further, I think that expecting software authors to realize the implications of using bind() without these additional maneuverings, with dire security consequences if they don't, is going to get us nothing but less secure systems. If this behavior is going to be continued in future revisions of any UNIX or UNIX-like OS, I think that this caveat should be well documented in the bind(2) manual page. > > In my opinion, ssh is clearly the buggy party here; not following > symlinks in the OS is just a workaround to avoid buggy programs > causing problems. We will only do this if we find that there are so > few legitimate consumers of the behaviour that we can change it > without problems - so far, we've only found one consumer, and it is > only of historic interest, being a part of FreeBSD itself (related to > /dev/log creation, IIRC) and only present in old versions. Perhaps, but it was certainly a subtle bug, and one I have not seen before on this list. The interaction between UNIX sockets and symlinks doesn't seem to be specified anywhere, and at least Solaris does not follow symlinks, so at any rate software which expects this behavior is not likely to be portable. My instincts say that when faced with unspecified behavior, it is probably wiser to choose the implementation that causes fewer security risks, unless there is a good reason to choose otherwise. Just my 2 cents, -------Scott. [1] "Unix Network Programming," W. Richard Stevens. First edition, page 263 (section 6.3).
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:06:38 PDT