From owner-freebsd-security Tue Jun 27 21: 8:18 2000 Delivered-To: freebsd-security@freebsd.org Received: from segfault.kiev.ua (segfault.kiev.ua [193.193.193.4]) by hub.freebsd.org (Postfix) with ESMTP id 7C2ED37B59E for ; Tue, 27 Jun 2000 21:08:12 -0700 (PDT) (envelope-from netch@nn.kiev.ua) Received: from nn.kiev.ua (nn.kiev.ua [193.193.193.203]) by segfault.kiev.ua (8) with ESMTP id HDB69389; Wed, 28 Jun 2000 07:07:59 +0300 (EEST) (envelope-from netch@nn.kiev.ua) Received: (from netch@localhost) by nn.kiev.ua (8.9.3/8.9.3) id HAA02829; Wed, 28 Jun 2000 07:08:04 +0300 (EEST) (envelope-from netch) Date: Wed, 28 Jun 2000 07:08:04 +0300 From: Valentin Nechayev To: Peter Wemm Cc: Warner Losh , freebsd-security@FreeBSD.ORG Subject: Re: O_NOFOLLOW Message-ID: <20000628070804.A2076@nn.kiev.ua> Reply-To: netch@segfault.kiev.ua References: <20000626094544.AEE461CD7@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <20000626094544.AEE461CD7@overcee.netplex.com.au>; from Peter Wemm on Mon, Jun 26, 2000 at 02:45:44AM -0700 X-42: On Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mon, Jun 26, 2000 at 02:45:44, peter (Peter Wemm) wrote about "Re: O_NOFOLLOW": > > : O_NOFOLLOW flag for open() syscall exists since 3.0-CURRENT and is quite > > : useful for secure open, but is not documented in open(2) man page yet. > > : Do FreeBSD team have its disclosing in plans? > > I'm not sure that it works from userland. At least that's what I > > recall from testing at one point... Now: ==={ netch@nn:~/tmp>rm -f direntry netch@nn:~/tmp>ln -s vasya direntry netch@nn:~/tmp>./11 open(): Too many links netch@nn:~/tmp>rm -f direntry netch@nn:~/tmp>touch direntry netch@nn:~/tmp>./11 S_ISREG st_dev=0x50304 st_ino=73214 st_rdev=0x0 netch@nn:~/tmp>uname -mrs FreeBSD 5.0-CURRENT i386 netch@nn:~/tmp>fgrep __FreeBSD_version /usr/include/sys/param.h #undef __FreeBSD_version #define __FreeBSD_version 500006 /* Master, propagated to newvers */ netch@nn:~/tmp> ===} hence, attempt to open symlink with O_NOFOLLOW fails with EMLINK. This is generated by code in vn_open(): === cut src/sys/kern/vfs_vnops.c === if (vp->v_type == VLNK) { error = EMLINK; goto bad; } === end cut === netch@nn:/usr/src/sys/kern>fgrep '$FreeBSD:' vfs_vnops.c * $FreeBSD: src/sys/kern/vfs_vnops.c,v 1.94 2000/05/26 02:04:40 jake Exp $ > The original issue was what to do if you actually got a symlink. In the > original implementation, you could open/read/write the symlink itself, but > there were some pretty evil constraints. What is "original implementation"? > As I recall, the currently committed code will let you open a symlink but > not read or write it. If you are intending to use it in a security role, > you still need to fstat it to make sure it is the file you intended and not > a handle on some symlink. This should be documented somehere.. It does not > return EISLINK or something like that when pointed at a symlink. According to descibed above I say this is not correct - vn_open() disables opportunity to open symlink. (But imho ELOOP should be returned in this case instead of EMLINK.) Imho it is already safe to use. -- NVA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message