Project

General

Profile

Actions
Copy link

Bug #1404

closed

MKDIR_P may not work correctly

Added by Valery Ushakov 5 months ago. Updated 2 months ago.

Status:
Resolved
Priority:
Low
Assignee:
Kienan Stewart
Target version:
-
Start date:
12/06/2023
Due date:
% Done:

0%

Estimated time:

Description

lttng-ust/doc/examples/Makefile.am uses MKDIR_P in a way that may (and does) fail under certain circumstances.

TL;DR: MKDIR_P may be a relative path, doesn't work if you do cd someplace else before using it.

The in-the-wild manifestation of this fallout scenario can be found e.g. here: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/54727

The story begins in autoconf that misdetects busybox mkdir as a suitable MKDIR_P: https://savannah.gnu.org/support/index.php?110971

When no suitable mkdir is found, autoconf uses its own install-sh, but it sets MKDIR_P to a relative path, adding more dot-dot segments as it walks down the source tree.

When lttng-ust/doc/examples/Makefile.am uses MKDIR_P it does it in a "wrong" directory and that relative path for MKDIR_P is invalid:
http://git.lttng.org/?p=lttng-ust.git;a=blob;f=doc/examples/Makefile.am;h=727aa7ceb5ab065651f69449834d87adaea50af6;hb=HEAD#l216

Actions
Copy link
 #1

Updated by Kienan Stewart 5 months ago

  • Status changed from New to In Progress
  • Assignee set to Kienan Stewart
  • Priority changed from Normal to Low

Hi Valery,

thanks for the bug report.

I've proposed a patch to fix this issue: https://review.lttng.org/c/lttng-ust/+/11488

Sidenote: as of autoconf 2.72d (2023-11-30), AC_PROG_MKDIR_P will no longer fall back to relative-pathed install-sh. C.f. https://github.com/autotools-mirror/autoconf/blob/49ab3a4c5756d7ef40b03111f4c8a351d6bca7b8/NEWS#L165

thanks,
kienan

Actions
Copy link
 #2

Updated by Kienan Stewart 2 months ago

  • Status changed from In Progress to Resolved
Actions
Copy link

Also available in: Atom PDF