Re: Use current directory for POSIX mkdir test in install-sh
On 10/10/06, Paul Eggert [EMAIL PROTECTED] wrote: 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. Ouch! That behavior is incorrect; it doesn't conform to POSIX. You might file a bug report, citing http://www.opengroup.org/onlinepubs/009695399/utilities/mkdir.html . Will do. Thanks for the link. This chmod(), even when failing, is considered an attempt to write to an external path, That's weird. mkdir(/, ...) is not considered to be an attempt to write to an external file name, but chmod (/, ...) is? This doesn't sound consistent to me; both system calls _attempt_ to write to an external file name. And neither _succeeds_ (which is what should matter here). So it sounds like your sandbox tests should be adjusted, one way or another, since they're not consistent. Yup, that's a known issue in the sandboxing code, and it would certainly trigger the mkdir call once fixed. But the fact of the attempt is what really matters, as we cannot predict if the call will fail, and if it succeeds it would actually change the file system, which is an unacceptable risk. Thanks, Alex
Re: install-sh misbehaves badly on buggy FreeBSD systems
Stepan Kasal [EMAIL PROTECTED] writes:
is there an implementation of mkdir which understands `-p' and `--' but
does not understand `-m'?
Not in the sense described here, no. Ancient mkdir treats all
arguments as directories to be made, and `$mkdirprog $mkdir_mode -p --
$tmpdir/d' must fail because tmpdir does not exist. I don't think
we need to worry about any mkdir understanding -p and -- but not -m;
even if there were an animal, it should treat -m as an unknown option
and should fail.
Your other ideas look good. It's a bit more consistent to test
dir_arg rather than mkdir_mode (that's what the rest of the script
does). So here's a revised patch.
2006-10-10 Paul Eggert [EMAIL PROTECTED]
* lib/install-sh (posix_mkdir): Reject FreeBSD 6.1 mkdir -p -m,
which incorrectly sets the mode of an existing destination
directory. In some cases the unpatched install-sh could do the
equivalent of chmod 777 / or chmod 0 / on a buggy FreeBSD
system. We hope this is rare in practice, but it's clearly worth
fixing. Problem reported by Alex in
http://lists.gnu.org/archive/html/bug-autoconf/2006-10/msg00012.html.
Also, don't bother to check for -m bugs unless we're using -m;
suggested by Stepan Kasal.
--- lib/install-sh.~1.35.~ 2006-07-09 09:09:31.0 -0700
+++ lib/install-sh 2006-10-10 12:05:29.0 -0700
@@ -336,12 +336,26 @@ do
trap 'ret=$?; rmdir $tmpdir/d $tmpdir 2/dev/null; exit $ret' 0
if (umask $mkdir_umask
- exec $mkdirprog $mkdir_mode -p -- / $tmpdir/d) /dev/null 21
+ exec $mkdirprog $mkdir_mode -p -- $tmpdir/d) /dev/null 21
then
- # Check for bugs in HP-UX 11.23 and IRIX 6.5 mkdir.
- case `ls -ld $tmpdir` in
- d-??-* ) posix_mkdir=:;;
- esac
+ if test -z $dir_arg || {
+ # Check for POSIX incompatibilities with -m.
+ # HP-UX 11.23 and IRIX 6.5 mkdir -m -p sets group- or
+ # other-writeable bit of parent directory when it shouldn't.
+ # FreeBSD 6.1 mkdir -m -p sets mode of existing directory.
+ ls_ld_tmpdir=`ls -ld $tmpdir`
+ case $ls_ld_tmpdir in
+d-?r-*) different_mode=700;;
+d-?--*) different_mode=755;;
+*) false;;
+ esac
+ $mkdirprog -m$different_mode -p -- $tmpdir {
+ls_ld_tmpdir_1=`ls -ld $tmpdir`
+test $ls_ld_tmpdir = $ls_ld_tmpdir_1
+ }
+}
+ then posix_mkdir=:
+ fi
rmdir $tmpdir/d $tmpdir
else
# Remove any dirs left behind by ancient mkdir implementations.
Re: Use current directory for POSIX mkdir test in install-sh
Alex Unleashed [EMAIL PROTECTED] writes: the fact of the attempt is what really matters, I'm afraid I'll have to disagree on this one, as a matter of philosophy. Autoconf regularly tries stuff to see whether it works. It's not at all unreasonable for Autoconf to try programs that have memory violations, or attempt to do other prohibited operations, in order for the Autoconf-generated code to discover what capabilities the system actually lets the installer do. If your sandboxing environment prohibits reasonable requests for information about what the environment allows, then it's being too strict. In this particular case, stricter auditing did find a bug in FreeBSD mkdir -p -m, and that's certainly a point in its favor. But I'm not sure it's a good idea in general. I guess I'd feel more comfortable with a sandbox where the installer ran as root, and actually could do a chmod 0 / or whatever, and where the auditing process discovered the sandbox was corrupted; I think this would detect problems like these more reliably. (Obviously though you're doing the work so it's up to you. :-)
Re: Use current directory for POSIX mkdir test in install-sh
On 10/10/06, Paul Eggert [EMAIL PROTECTED] wrote: Alex Unleashed [EMAIL PROTECTED] writes: the fact of the attempt is what really matters, I'm afraid I'll have to disagree on this one, as a matter of philosophy. Autoconf regularly tries stuff to see whether it works. It's not at all unreasonable for Autoconf to try programs that have memory violations, or attempt to do other prohibited operations, in order for the Autoconf-generated code to discover what capabilities the system actually lets the installer do. If your sandboxing environment prohibits reasonable requests for information about what the environment allows, then it's being too strict. Hi Paul, I guess that by 'reasonable request' you mean some potentially harmful operation resulting in non-modified file system. The problems arising here from a QA viewpoint are: 1) How to determine that a request is 'reasonable'. Since all write requests will invariantly be denied, the sandbox could be relaxed by checking that the call will be actually innocuous, thus not ringing the alarms. I think this can be done. 2) How to determine that the request, even when 'reasonable', is due to a legal and well-known test and not due to something misbehaving badly. Being a QA tool, the sandbox has to identify the latter. Without getting my hands dirty on a really ugly hack I can't imagine how to deal with this. I understand that those innocuous tests might be needed outside the working directory (though the install-sh one is about the only one I know of). In fact mkdir() not showing up is because the code was relaxed to silence requests on existing directories (still don't know if intentionally) even when the path is clearly out of the sandbox. Maybe changing this will reveal some other inconsistencies elsewhere. I guess I'd feel more comfortable with a sandbox where the installer ran as root, and actually could do a chmod 0 / or whatever, and where the auditing process discovered the sandbox was corrupted; I think this would detect problems like these more reliably. (Obviously though you're doing the work so it's up to you. :-) Well, the installer actually runs as root, it's just that the sandboxing wrapper prevents some dangerous calls from actually getting executed. In fact the current sandbox code is working fairly well for most of Gentoo's packages built from sources, and that's quite a lot. This case is an exception, and it proved something was indeed wrong. Anyway, thanks for your suggestion, the problem is currently fixed with the patched mkdir. PS: FreeBSD's mkdir has already been fixed in CVS, I hope next version ships it. Regards, Alex
