Re: makewhatis and homebrew

[Ingo Schwarze <schwarze@usta.de>]

Kristaps Dzonsons wrote on Tue, Dec 09, 2014 at 01:22:05PM +0100:

> When I'm forced to use OS X, I'm forced to use  "homebrew" to manage
> software.  What this does is, instead of installing software, it
> links the software to a magical location, e.g.,
> 
> /usr/local/share/man/man1/itstool.1@ ->
> ../../../Cellar/itstool/2.0.2/share/man/man1/itstool.1

Yikes.

Specifically designed to be insecure:

  /usr/local/share/man/man1/mostly_harmless@->
  ../../../../../etc/master.passwd

> These manuals don't appear anywhere in man(1) now because they're
> outside of the chdir.  In fact, when I run makewhatis with -p, I see
> many more of these from the base system installation:
> 
> /usr/share/man/: /System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/Documentation/man/jstat.1:
> outside base directory
> 
> (Which is linked from /usr/share/man/man1/jstat.1.)
> 
> ...etc.
> 
> Is there a way to relax this constraint,

Deleting the five lines

	if (strstr(buf, basedir) != buf) {
		if (warnings) say("",
		    "%s: outside base directory", buf);
		continue;
	}

should just work.  The file will be treated as if it resided at the
place where the symlink was found.

Note, though, that this is not a functionality check,
but a *security* check you are deleting, so we cannot
possibly commit it to the repository.  If it works,
we could introduce a compile time switch (with a big red
warning) to allow it, if you consider that helpful.

> or would that break
> anything further into the parse sequence, i.e., so's?

Well, .so is fragile in the first place, and this madness is
certainly not making it any better.  I hope those crazy people
don't combine the above with .so...  Or if they do, the .so
will be resolved relative to the directory where the symlink
resides, not relative to the directory of the file pointed to.

Yours,
  Ingo
--
 To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv