From dada@sbox.tugraz.at  Tue Dec  9 06:54:25 2003
Return-Path: <dada@sbox.tugraz.at>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 2D0FB16A4CE
	for <freebsd-gnats-submit@freebsd.org>; Tue,  9 Dec 2003 06:54:25 -0800 (PST)
Received: from mailrelay02.tugraz.at (mailrelay.tu-graz.ac.at [129.27.3.7])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 5803343D28
	for <freebsd-gnats-submit@freebsd.org>; Tue,  9 Dec 2003 06:54:23 -0800 (PST)
	(envelope-from dada@sbox.tugraz.at)
Received: from localhost (webmail01.tu-graz.ac.at [129.27.3.143])
	by mailrelay02.tugraz.at (8.12.10/8.12.10) with ESMTP id hB9EsJ1n025939;
	Tue, 9 Dec 2003 15:54:19 +0100 (CET)
Received: from ABRZ173.kfunigraz.ac.at (ABRZ173.kfunigraz.ac.at
	[143.50.106.173]) by webmail.tugraz.at (Horde) with HTTP for <dada@sbox>;
	Tue,  9 Dec 2003 15:54:20 +0100
Message-Id: <20031209155420.owco000444w4g0g4@webmail.tugraz.at>
Date: Tue,  9 Dec 2003 15:54:20 +0100
From: dada@sbox.tugraz.at
To: freebsd-gnats-submit@freebsd.org
Subject: realpath(3) accepts zero size symbolic links

>Number:         60079
>Category:       bin
>Synopsis:       realpath(3) accepts zero size symbolic links
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Dec 09 07:00:35 PST 2003
>Closed-Date:    Sun May 30 09:45:48 PDT 2004
>Last-Modified:  Sun May 30 09:45:48 PDT 2004
>Originator:     Martin Kammerhofer
>Release:        FreeBSD 4.9-STABLE i386
>Organization:
Graz University
>Environment:
System: FreeBSD Martin.liebt.Susi 4.9-STABLE FreeBSD 4.9-STABLE #0: Thu Nov 20
21:46:53 CET 2003 toor@Martin.liebt.Susi:/usr/obj/usr/src/sys/LEND4 i386
	Applies to -current and -stable.
>Description:
	The libc realpath(3) routine accepts zero size symbolic links
	without returning any error indication. Since namei(9) will
	never accept such a path this behaviour is misleading and
	could confuse applications.

	BTW Revision 1.13 of src/lib/libc/stdlib/realpath.3 needs a
	MFC.
>How-To-Repeat:
	/var/tmp$ ln -s "" ZEROLINK
	/var/tmp$ realpath ZEROLINK
	/var/tmp
	/var/tmp$ realpath ZEROLINK/vi.recover
	/var/tmp/vi.recover
>Fix:
--- src/lib/libc/stdlib/realpath.c.orig	Tue Dec  9 12:48:48 2003
+++ src/lib/libc/stdlib/realpath.c	Tue Dec  9 12:52:27 2003
@@ -149,11 +149,14 @@
 				return (NULL);
 			}
 			slen = readlink(resolved, symlink, sizeof(symlink) - 1);
-			if (slen < 0)
+			if (slen <= 0) {
+				if (slen == 0)
+					errno = ENOENT;
 				return (NULL);
+			}
 			symlink[slen] = '\0';
 			if (symlink[0] == '/') {
-				resolved[1] = 0;
+				resolved[1] = '\0';
 				resolved_len = 1;
 			} else if (resolved_len > 1) {
 				/* Strip the last path component. */

>Release-Note:
>Audit-Trail:

From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
To: dada@sbox.tugraz.at
Cc: freebsd-gnats-submit@freebsd.org
Subject: bin/60079: realpath(3) accepts zero size symbolic links
Date: Wed, 10 Dec 2003 15:57:12 -0500 (EST)

 <<On Tue,  9 Dec 2003 15:54:20 +0100, dada@sbox.tugraz.at said:
 
 > 	The libc realpath(3) routine accepts zero size symbolic links
 > 	without returning any error indication. Since namei(9) will
 > 	never accept such a path this behaviour is misleading and
 > 	could confuse applications.
 
 If namei(9) doesn't accept such a path it is broken.  POSIX clearly
 (well, actually, murkily but definitively) specifies the (very
 unintuitive) meaning of such a symbolic link.
 
 -GAWollman
 

From: dada@sbox.tugraz.at
To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Cc:  
Subject: Re: bin/60079: realpath(3) accepts zero size symbolic links
Date: Fri, 12 Dec 2003 13:15:01 +0100

 Zitat von Garrett Wollman <wollman@khavrinen.lcs.mit.edu>:
 
 > If namei(9) doesn't accept such a path it is broken.  POSIX clearly
 > (well, actually, murkily but definitively) specifies the (very
 > unintuitive) meaning of such a symbolic link.
 
 I=B4m surprised. I didn=B4t consider that standards could specify such stran=
 ge
 semantics. However realpath(3) and namei(9) do not match here. Zero size
 symbolic links make the kernel return ENOENT. (Verified on -stable.)
 
 Fixing namei(9) is a different subject and - if desirable at all - should go
 into a PR of its own. I therefore withdraw this PR because it is apparently =
 not
 POSIX conformant. Please someone close it! (MFC of the realpath.3 manpage
 should be done however. It is out of sync with the code in -stable.)
 
 P.S.: BTW Linux=B4s symlink(2) doesn=B4t even create such a strange symbolic=
  link.
 
 
State-Changed-From-To: open->closed 
State-Changed-By: dwmalone 
State-Changed-When: Sun May 30 09:42:47 PDT 2004 
State-Changed-Why:  
Closed at submitter's request. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=60079 
>Unformatted:
