From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from scc-mailout-kit-01-web.scc.kit.edu (scc-mailout-kit-01-web.scc.kit.edu [129.13.231.93]); by fantadrom.bsd.lv (OpenSMTPD) with ESMTP id 8bbda55f; for ; Sat, 17 Jan 2015 22:33:40 -0500 (EST) Received: from asta-nat.asta.uni-karlsruhe.de ([172.22.63.82] helo=hekate.usta.de) by scc-mailout-kit-01.scc.kit.edu with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (envelope-from ) id 1YCgcK-0004ru-S4; Sun, 18 Jan 2015 04:33:37 +0100 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.77) (envelope-from ) id 1YCgcK-0001Jm-JT; Sun, 18 Jan 2015 04:33:36 +0100 Received: from iris.usta.de ([172.24.96.5] helo=usta.de) by donnerwolke.usta.de with esmtp (Exim 4.80) (envelope-from ) id 1YCgcK-00061x-1w; Sun, 18 Jan 2015 04:33:36 +0100 Received: from schwarze by usta.de with local (Exim 4.77) (envelope-from ) id 1YCgcJ-0003Ie-OC; Sun, 18 Jan 2015 04:33:35 +0100 Date: Sun, 18 Jan 2015 04:33:35 +0100 From: Ingo Schwarze To: Alexis Cc: tech@mdocml.bsd.lv, Kristaps Dzonsons Subject: Re: Allow configure variables to be set from environment Message-ID: <20150118033335.GA16562@iris.usta.de> References: <20150116215840.GF740@kei.fritz.box> <20150117010706.GH9772@iris.usta.de> <54BAC1A2.2060907@bsd.lv> X-Mailinglist: mdocml-tech Reply-To: tech@mdocml.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54BAC1A2.2060907@bsd.lv> User-Agent: Mutt/1.5.21 (2010-09-15) Hi Alexis, hi Kristaps, Kristaps Dzonsons wrote on Sat, Jan 17, 2015 at 09:10:10PM +0100: > Ingo's right on this one, but let's think a bit more. There are a > lot of OS X people out there and a lot of them use homebrew. I > think it's worthwhile to have (or at least consider having) an > official mandoc in homebrew, Thank you for clarifying that. That's precisely how i feel, but indeed i didn't make that clear. When something annoys me, i'm sometimes a bit brusque. > but it should be done right. Doing a naive installation isn't enough. > > The problem, as mentioned, is that makewhatis(8) won't pick up any > homebrew manuals, making mandoc(1) only useful as a standalone > binary operating directly on manpages (e.g., mandoc path/to/manpage.1). Exactly. > You can patch makewhatis(8) not to check if the manpage is looking > at symlinks outside of the MANPATH, but that's effectively opening > up a security hole where mandoc(1) tools might be run on basically > anything. I'd thoroughly hate that. If you do that, i will remove all reference to your port from the homepage, and if need be, publish a statement that you deliberately patch vulnerabilities into software you are porting, urging people to not use your work. > (By the way, did you plan on cron'ing makewhatis(8) or anything?) > > If you don't patch makewhatis(8) and install it as-is, you're going > to confuse users when their manpages don't show up when using the > other tools installed with the package (apropos, man, etc.) or when > running the respective mandoc arguments (-a, -f, etc.). > > So either you patch makewhatis(8) or patch the installation to > *only* install mandoc, then patch mandoc to omit -f, -k, and -a, and > not respond to being invoked as apropos, whatis, or man. No patching is needed. Just set BUILD_DB=0 in configure.local, it cleanly does all Kristaps is describing. If you do that, it would be honest to add a note to the port that people read when they install that mandoc can't be used as a man(1) replacement with homebrew *because homebrew has security issues*. Make it clear that the security issues lay with homebrew, *not with mandoc*, and that *any* other man(1) they might install *is likely to either have the same security issues or not work for the same reasons as mandoc*. Oh wait a minute. I think i see a solution. If we specifically allow mandoc to follow symlinks only into the homebrew tree, but nowhere else, that seems safe. It's a bit tricky to avoid race conditions, but i think there is a secure way to implement it. Is there are standardized place where homebrew installs its real files, and where nobody in their right mind would ever put any confidential data? Maybe /Cellar? Is that right? If you can confirm that, i might add official /Cellar support to mandoc. > Essentially, the question is whether you want mandoc as a > constellation of tools (a man replacement) with security tools > or a developer tool. If you are a user of homebrew, you can ask the question even more pointedly: Do you want your system to be able to securely show manual pages, even to a user logged in as a superuser, for example root or any other high-privileged user having read access to confidential files - the problem might arise even for regular users if they own files that are in any way confidential, which may even be a problem for their own files in their own home directory, depending on the attack scenario. If you want to securely show manuals installed by homebrew with *any* implementation of man(1), more is needed than a port of some random man(1) implementation. > I don't know what the correct solution is here. > Bref, homebrew has issues. True, but the above might be a solution. If we manage to support that, it would actually be a safe man(1) for homebrew, much safer than the traditional BSD or man-db implementations. Yours, Ingo -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv