Bugzilla Bug 144594

Here's the problem: aclocal wants to set $(mkdir_p) to a command like the POSIX
compliant "mkdir -p --". FreeBSD's mkdir supports this (it is POSIX compliant)
but aclocal specifically checks for GNU mkdir using the "--version" switch.
This results in GNU mkdir being the only one supported, and when not found
aclocal sets $(mkdir_p) to the fallback install-sh script suffixing the "-d"
switch (check out aclocal.m4).

While this is nothing more than a little nuisance, it happens to be more than
that when the script is actually used instead of mkdir. install-sh does also
test the mkdir binary for POSIX compliance, and it does that in a way that
breaks sandbox causing violations (with the command "mkdir -m
u=rwx,g=rx,o=rx,u+wx -p -- /", note the path being the root directory).

This happens when packages install themselves using this, like libtool does.
These packages will be causing sandbox violations on platforms without GNU
mkdir unless aclocal.m4 or install-sh get patched. I don't know of other
packages right now affected by this issue, but whatever uses $(mkdir_p) in the
install phase will fail when sandboxed. Violations caused by this can be easily
identified because of the mkdir command and the specific violation being "chmod
/".

So, we'd need to patch aclocal.m4 and make sure than anything that uses this
gets patched.

Mike, do you have anything to experiment with in respect to the automatic
patching of configure/autotools data? I'd be willing to take a look for this,
too.

no, nothing yet from me

So, we cannot actually fix this by just changing the aclocal output, because
mkdirp.m4 is installed by automake. We cannot fix this by adding mkinstalldirs,
as libtool itself uses install-sh script. We need to fix install-sh so that it
does not try to create / but something different ... ideas?

This is a big problem. We could go and patch install-sh at build time but even
then packages could still be released upstream with different install-sh
scripts. I couldn't quite test the new version of GNU m4 to actually see if
it's hitting this bug too, but if it is (quite likely), the install-sh script
did test mkdir with a similar but slightly _different_ line. And while
investigating this there seemed to be some changes upstream, but nothing going
to fix this anyway. An easier solution would be to patch install-sh to set the
posix variable to true and skip the tests altogether (it's less likely to be
changed so we could apply it even if the test changed).

We could also ask upstream to stop using --version or at least have some
specific tests for other mkdir versions which are actually known to be POSIX
compliant before falling back to install-sh. Perhaps asking them to use .
instead of / in install-sh might do the trick for the future, but the problem
would still remain with current software.

Quite frankly, I cannot see a solution to this other than patching on the fly
and waiting for upstream to actually care for other mkdir versions (or change
the stupid test).

Ok, I'm back at home, sweet home :). I've come up with the following proposal:

1) Add a function named something like fix_install-sh to portability.eclass
(maybe another eclass?). Yes, that function name sucks...

Code could look like this:

fix_install-sh() {
  ebegin Fixing install-sh to be sandbox-safe
  find ${S} -name install-sh -print0 | xargs -0 sed -i -e 's:-p -- / :-p -- .
:g'
  eend $?
}

2) Run fix_install-sh in src_install before issuing make install in affected
ebuilds.

Alternatively it could be run silently and/or every time src_install is called.

I have tested it and both libtool and m4 ebuilds (they have different
install-sh files, btw) worked flawlessly once they were patched to first call
that function in src_install.

Thoughts?

no, the point here is to stop adding functions to eclasses

we want to integrate all of these automatic autotool patching into portage
(like we do now with config.{sub,guess})

Mike what would it be if we were to fix libtool's install-sh, then make econf
copy that together with config.* stuff?

the reason helper scripts are generally bundled is because they are intertwined

this is why you cant update the libtool helper script without updating the
configure/m4 code as well

while in most cases i imagine this wouldnt be a problem for
install-sh/missingdirs/etc..., i think it migt be saner to go a patch route
like we do with libtool ... i havent really looked at these scripts at all

So I guess the proper course of action here is to patch ebuild.sh with
basically the suggested function, isn't it?

What should be patched? econf()? Note that we can defer actual patching until
src_install.

ideally it'd be a post-src_unpack hook i think ... we could even move the
config.{sub,guess} updating there as well

Hey, is there anything being done on portage about this? The fix is so
straightforward that it'd be a shame to miss it for G/FBSD 6.2.

I have an idea for a temporary solution: use the bashrc unpack hook I already
have in place to check for broken gnulib.

> The fix is so straightforward that it'd be a shame to miss it for G/FBSD 6.2.

you mean a temporary hack ?  thanks, but no ... that isnt going into portage,
nor is it going into an eclass

That's why I said bashrc, limited to G/FBSD not to interfer with anything,
while we don't have any other way to get around this.

(In reply to comment #13)
> you mean a temporary hack ?  thanks, but no ... that isnt going into portage,
> nor is it going into an eclass

No, I'm the kind of person who better likes _permanent_ hacks ;). Now
seriously,  I didn't mean the eclass thing, I meant the possible fix you
sketched, a hook dealing with all autotools patching (or just adding what's
needed for current patching if that isn't happening yet). Thus I was asking
whether this issue is being tracked at all by portage developers, so I could
decide if it's really needed for me to send them (quite obvious) patches to get
things moving.

This and OpenSSL violations (#138344) are the two main culprits holding back
sandbox support in Gentoo/FreeBSD. I'd rather have them discussed and fixed as
soon as possible, specially since they aren't really complex.

putting it into a profile-specific bashrc would be the less evil hack ... but
doing so would give people no motivation really to fix it properly ;)

ewarn "This is bad, your package has a problem with the install-sh script, see
bug #144594."

Add to that a patch to libtool, so that its copy of install-sh is fixed, and
then everything using eautoreconf will be fixed automatically. Send the patch
upstream and we'd be done.

Hello again guys, I had an interesting conversation with Paul Eggert
(http://lists.gnu.org/archive/html/bug-autoconf/2006-10/msg00012.html) from
autotools and he insisted in supporting the root directory in install-sh
because of some really odd NFS issues in some weird setups (*sigh*, looks like
they originally used the current directory and switched to root because of
that).

While discussing and comparing mkdir sources I discovered FreeBSD's mkdir
deviating in behaviour from GNU's, chmod()'ing the specified directory even
when it didn't create it, ultimately proving not to adhere to POSIX specs
(http://lists.freebsd.org/pipermail/freebsd-hackers/2006-October/018259.html).

There's also a sandbox hack ignoring mkdir()'s on existing directories before
checking if the directory is external (which I did also notice before and will
discuss with azarah once he gets back), which is why the violation was telling
about chmod() and not mkdir() in the first place (as should've probably
happened).

Anyway, going more to the point, current solution is to fix FreeBSD's mkdir to
conform to POSIX applying this patch:
http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/mkdir/mkdir.c.diff?r1=1.32&r2=1.33

I'm sorry, but this time I don't know if this will make it for 6.2, however I
wouldn't count much on it.

Important thing to note is that patching mkdir will be sufficient for now *only
because* sandbox currently allows mkdir("/", ...), which might change in the
future, depending on what azarah says -- and instead it didn't allow chmod("/",
...). If it won't allow mkdir() calls like that, this will need to be brought
back to attention and we'll probably have to disagree with upstream about
install-sh.

Finally, this might affect other OSes (with non-GNU and faulty mkdir
implementations) once they get supported by Gentoo (seems like OpenBSD is not
affected, as reported by someone on IRC, but can't say for NetBSD or others).

Added patch to freebsd-bin, thx