Windows requires tar extraction to happen in a separate process, as manipulating layers requires a process wide escalation of privilege. Discussing offline with @dmcgowan, we were wondering if it made sense to do this isolation on Linux as well.
This issue is to discuss the following:
- Does it make sense to isolate the tar extraction on Linux too?
- If so, what would the interface be?
- The method for isolating this in a separate process.
Regarding 2: The current interface I'm using (specific to Windows layer Apply) is tar stream via stdin, numbered args for home dir, layer ID, parent paths, return value to indicate failure, size written returned by stdout, and errors on stderr.
I'm still looking to solve the problem of logging in the separate process, and correlating these to the main daemon logs.
Regarding 3: I currently see two possible approaches to this, re-exec, and a separate binary. From discussion with @crosbymichael, containerd was attempting to avoid the re-exec model, but I think the ease of deployment with a single binary is worth a discussion of the merits of this approach. I've got both working as prototypes.
Separate binary
Advantages:
- Prevents binary bloat
- Avoid the memory overhead of starting the entire daemon binary when extracting
Rexec
Advantages:
- A single binary is easy to deploy
Disadvantages:
- Re-exec is prone to be abused when it is easy to do
@crosbymichael @dmcgowan @stevvooe @mlaventure
Windows requires tar extraction to happen in a separate process, as manipulating layers requires a process wide escalation of privilege. Discussing offline with @dmcgowan, we were wondering if it made sense to do this isolation on Linux as well.
This issue is to discuss the following:
Regarding 2: The current interface I'm using (specific to Windows layer Apply) is tar stream via stdin, numbered args for home dir, layer ID, parent paths, return value to indicate failure, size written returned by stdout, and errors on stderr.
I'm still looking to solve the problem of logging in the separate process, and correlating these to the main daemon logs.
Regarding 3: I currently see two possible approaches to this, re-exec, and a separate binary. From discussion with @crosbymichael, containerd was attempting to avoid the re-exec model, but I think the ease of deployment with a single binary is worth a discussion of the merits of this approach. I've got both working as prototypes.
Separate binary
Advantages:
Rexec
Advantages:
Disadvantages:
@crosbymichael @dmcgowan @stevvooe @mlaventure