Re: Allow configure variables to be set from environment

[Ingo Schwarze <schwarze@usta.de>]

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