spec: implement path blacklist, and change path (white|black)list semantics

[cgonyeo]

I'd like to talk about the path whitelist, and how it could be changed to make implementing things like acbuild easier. It appears that the reason it exists is to allow layers to "delete" files from layers below them.

With the way the path whitelist is currently defined, if acbuild is used to modify an image without a whitelist and add a dependency with a whitelist, acbuild must fetch all other dependencies for the image being modified, construct its rootfs, and walk it to generate a path whitelist for the given image to be merged with the whitelist from the image being added.

I'd like to suggest two things:

• Switch to a path blacklist, where only files that are being removed from a lower layer will be listed.
• Have the ACE evaluate the path blacklist for every layer, instead of just the topmost one.

For the first suggestion, it makes more sense to me to list what has been removed from lower layers, since I think this list will be far shorter in most situations than all the files that still exist in lower layers.

To elaborate on the second suggestion, if layer A has file /foo, layer B has a dependency on layer A and layer B has a blacklist with /foo on it, and layer C has a dependency on layer B and an empty path blacklist, then /foo will not show up in layer C.

With the current situation, simply adding a dependency to the manifest in an ACI isn't sufficient to correctly add the dependency, since the path (white|black)lists for dependencies aren't evaluated by the ACE.

[cgonyeo]

Related: #323 containers/build#9

[cgonyeo]

I mostly want my second suggestion, where the list is evaluated at every layer. The blacklist would just be a nicety (and having an optional blacklist alongside the whitelist would be fine with me).

[jonboulle]

Why not just add blacklists as optional, as discussed in #323, implementing the semantics you're talking about - then there's no need to touch whitelists as they are today, right?