Date: Sun, 28 Mar 2004 01:04:13 +0100 From: Jilles Tjoelker <jilles+fbsd-arch@stack.nl> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: freebsd-arch@freebsd.org Subject: Re: fchroot(2) and others. Message-ID: <20040328000413.GA6185@stack.nl> In-Reply-To: <20040327203620.GR8930@darkness.comp.waw.pl> References: <20040327203620.GR8930@darkness.comp.waw.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040328000413.GA6185>