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
