Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: why no chroot()? #107

Closed
anguslees opened this issue Apr 17, 2018 · 3 comments
Closed

Question: why no chroot()? #107

anguslees opened this issue Apr 17, 2018 · 3 comments

Comments

@anguslees
Copy link

anguslees commented Apr 17, 2018

From my read of the designdoc and quick look at the code, I think kaniko works by unpacking the image onto the real (inside the container) / and just assuming that the kaniko machinery can stay out of the way of the user's container data via an explicit whitelist.

I'm curious: Why not unpack into a subdir, and chroot() there when it's time to RUN commands? That way the "working directory" root is cleanly separated from the actual kaniko agent's root filesystem. From what I can see, kaniko already assumes it is running as uid=0 (correct?) to preserve file permissions, run commands (apt-get) as root, etc so invoking chroot() should work just fine.

(I feel like this is such an obvious approach that I was expecting to see it mentioned in the docs, with an explanation of why it wasn't the approach taken. I'm hoping to discover that reason with this issue/question...)

@dlorenc
Copy link
Contributor

dlorenc commented Apr 17, 2018

Really good question! chroot can't be run inside a default container in kubernetes or docker without the --privileged flag.

I've been playing around with a version of this that uses proot/ptrace to fake a chroot, I think it can work here and help reduce privileges.

@dlorenc
Copy link
Contributor

dlorenc commented Apr 17, 2018

Actually, it looks like my memory on this was wrong. It's the "mount --bind" that many programs use to populate a chroot before using that causes trouble inside a standard container that doesn't have the --privileged flag.

docker run -it alpine sh
mkdir newroot
cd newroot/
mkdir bin lib
cp -r /bin/* bin/
cp -r /lib/* lib/
chroot /newroot /bin/sh

We should probably do this to help separate the unpacking from the base kaniko directories. I don't think it would help much with dropping privileges though, because we'd still need to be root to create the initial rootfs.

@priyawadhwa
Copy link
Contributor

I tried using chroot to execute commands in a subdirectory. Since we can't use "mount --bind" I had to copy over relevant directories (/proc, /dev, /sys, /etc). Copying basically took forever and didn't really work, so I don't think we'll be able to use chroot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants