bug-automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Use current directory for POSIX mkdir test in install-sh


From: Alejandro Martínez Ruiz
Subject: Re: Use current directory for POSIX mkdir test in install-sh
Date: Tue, 10 Oct 2006 23:23:50 +0200

On 10/10/06, Paul Eggert <address@hidden> wrote:
"Alex Unleashed" <address@hidden> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]