On 10/9/06, Paul Eggert <[EMAIL PROTECTED]> wrote:
Sorry, but this fix causes install-sh to deduce the wrong
answer if the working directory is not searchable.
Yes, you are right, and I didn't think about this possibility. However I
just find it hard to imagine having such permissions when installing
software. Is there any real world package running install-sh on such
directories (maybe I'm missing something here)? Should that be supported at
all?
Sorry, I don't follow. When using GNU mkdir, the test
doesn't write anything to external paths. It does invoke
mkdir("/", ...) but that mkdir must fail, so nothing can be
written.
What does the non-GNU mkdir do, that messes up your auditing
procedure? Surely it doesn't actually _write_ anything to
'/'. If we know more about the actual problem, perhaps we
can come up with a solution.
The difference with other mkdir versions is that GNU mkdir does not try to
chmod() the directory if it didn't just create it. The mkdir I'm currently
testing is FreeBSD's. It always chmod()'s the directory when a mode is
specified, no matter it didn't create it. This chmod(), even when failing,
is considered an attempt to write to an external path, which shouldn't
happen when building software, and gets caught by the sandbox checks.
Looking at this difference in behaviour, and guessing that it's correct to
only chmod() those directories mkdir just created (haven't really looked
into this), I think I'll have to fall back to patching mkdir implementations
out there doing this if the "." solution doesn't really work, which is what
I wanted to avoid. :-/
Thank you,
Alex
