Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 16 Jan 2002 13:06:20 -0700
From:      Nate Williams <nate@yogotech.com>
To:        Robert Watson <rwatson@FreeBSD.org>
Cc:        Ruslan Ermilov <ru@FreeBSD.org>, 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:  <15429.56636.984304.733778@caddis.yogotech.com>
In-Reply-To: <Pine.NEB.3.96L.1020116145639.73036A-100000@fledge.watson.org>
References:  <20020116195429.J13904@sunbay.com> <Pine.NEB.3.96L.1020116145639.73036A-100000@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
> 
> > 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.

My thinking is that it's just as easy to get root from a normal user as
it is to get it from man, so we're really not gaining a whole lot (from
the point of view of root compromises).

Regardless, there are still other concerns with over-writing files and
such that are annoying, if not necessarily security holes in the sense
of getting root access.


Nate

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?15429.56636.984304.733778>