From owner-freebsd-arch@FreeBSD.ORG Sat Mar 27 16:04:16 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3AD916A4CF; Sat, 27 Mar 2004 16:04:15 -0800 (PST) Received: from hexagon.stack.nl (hexagon.stack.nl [131.155.140.144]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4160343D31; Sat, 27 Mar 2004 16:04:15 -0800 (PST) (envelope-from jilles@stack.nl) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010:2e0:81ff:fe22:51d8]) by hexagon.stack.nl (Postfix) with ESMTP id 4066167E#4DE275171; Sun, 28 Mar 2004 01:04:14 +0100 (CET) Received: by turtle.stack.nl (Postfix, from userid 1677) id 1A5D81CC2E; Sun, 28 Mar 2004 01:04:14 +0100 (CET) Date: Sun, 28 Mar 2004 01:04:13 +0100 From: Jilles Tjoelker To: Pawel Jakub Dawidek Message-ID: <20040328000413.GA6185@stack.nl> References: <20040327203620.GR8930@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040327203620.GR8930@darkness.comp.waw.pl> X-Operating-System: FreeBSD 5.2.1-RELEASE-p1 i386 User-Agent: Mutt/1.5.6i cc: freebsd-arch@freebsd.org Subject: Re: fchroot(2) and others. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2004 00:04:16 -0000 On Sat, Mar 27, 2004 at 09:36:20PM +0100, Pawel Jakub Dawidek wrote: > Are we interested in fchroot(2) syscall? It exists in NetBSD. How's that better than chdir(CHROOTDIR); chroot("."); ? NetBSD seems to have implemented it for SunOS/Solaris compatibility. > If so, its implementation is in pjd_secure_syscalls branch or > at: > http://people.freebsd.org/~pjd/patches/secure_syscalls.patch > I've also impelemnted safe versions of other syscalls: > int flink(int fd, const char *link); This means that you can access a file forever when you get a descriptor on it once, which may not be desired. In any case, this gives more rights than normal. You could mitigate this by requiring the caller to own the file, or by following the same approach (fd+name) as in funlink() and frename(). > int funlink(int fd, const char *path); > int frename(int fd, const char *from, const char *to); Looks good, but I don't really know whether it's worth the extra syscalls. It's not much use if find -unlink doesn't use them. > Maybe funlink(2) and frename(2) looks wired, but it should work. > The idea is, that one cannot pass descriptor number only to those > functions, because they're operating on file systems object names > and there is no clean way to get path name from descriptor. It's actually impossible to get the path name, there may be zero names, or more than one. -- Jilles Tjoelker