Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 16 Jan 2002 15:00:41 -0500 (EST)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Ruslan Ermilov <ru@FreeBSD.org>
Cc:        Joerg Wunsch <j@uriah.heep.sax.de>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, arch@FreeBSD.org
Subject:   Re: cvs commit: src/gnu/usr.bin/man/man Makefile man.c src/etc/mtree BSD.local.dist BSD.usr.dist BSD.x11-4.dist BSD.x11.dist
Message-ID:  <Pine.NEB.3.96L.1020116145639.73036A-100000@fledge.watson.org>
In-Reply-To: <20020116195429.J13904@sunbay.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On Wed, 16 Jan 2002, Ruslan Ermilov wrote:

> There's still problem exists with following symbolic links (please see
> the PR for an example exploit).  I tried a quick patch that should solve
> this, but Robert Watson pointed out that it is subject to a race between
> lstat(2)'ting a directory holding a catpage and creating a file in that
> directory.  Unfortunately, O_NOFOLLOW only works for the last component
> of the pathname passed to open(2).  If we could find a solution to this
> problem, I would be more than happy to restore this functionality of
> man(1). 

Part of the problem here is that man's behavior is very complex, and the
UNIX inheritence model makes things rather messy.  Simply eliminating
dynamically cached catpages eliminates the risk associated with the model,
and is my preferred solution.  It's not hard to imagine tactics to
escalate privilege from user man to user root in the event that the man
program or any children running as uid of man are compromised.  I'm happy
with the behavior being available and turned off by default, but
personally my feeling is that the performance/correctness tradeoff leans
towards correctness given the risk.  And to be honest, people don't
usually benchmark systems based on the time it takes to render a man page. 
:-)

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org      NAI Labs, Safeport Network Services



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020116145639.73036A-100000>