From a88e8a8f894a2084ca6ae7f6c2b56b26f2230f24 Mon Sep 17 00:00:00 2001
From: timbavtbc <156712895+timbavtbc@users.noreply.github.com>
Date: Mon, 22 Jan 2024 10:28:11 +0000
Subject: [PATCH] Clarify why merging into another container is a bad idea

I tend to read 'YMMV' as 'might need some jiggling'. I think being explicit about the particular implementation details is more useful here.
---
 README.md | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/README.md b/README.md
index 428d49d398..822936ed51 100644
--- a/README.md
+++ b/README.md
@@ -19,7 +19,7 @@ standard Kubernetes cluster.
 
 kaniko is meant to be run as an image: `gcr.io/kaniko-project/executor`. We do
 **not** recommend running the kaniko executor binary in another image, as it
-might not work.
+might not work as you expect - see [Known Issues](#known-issues).
 
 We'd love to hear from you! Join us on
 [#kaniko Kubernetes Slack](https://kubernetes.slack.com/messages/CQDCHGX7Y/)
@@ -150,9 +150,12 @@ image (if there are any) and update image metadata.
 
 - kaniko does not support building Windows containers.
 - Running kaniko in any Docker image other than the official kaniko image is not
-  supported (ie YMMV).
+  supported due to implementation details.
   - This includes copying the kaniko executables from the official image into
-    another image.
+    another image (e.g. a Jenkins CI agent).
+  - In particular, it cannot use chroot or bind-mount because its container must
+    not require privilege, so it unpacks directly into its own container root
+    and may overwrite anything already there.
 - kaniko does not support the v1 Registry API
   ([Registry v1 API Deprecation](https://engineering.docker.com/2019/03/registry-v1-api-deprecation/))