When updateNames() copies an image's record from a read-only store into
the read-write store, copy the accompanying data as well.
Add fields for setting data items at creation-time to LayerOptions,
ImageOptions, and ContainerOptions to make this easier for us and our
consumers.
Replace the store-specific Create() (and the one CreateWithFlags() and
Put()) with private create() and put() methods, since they're not
intended for consumption outside of this package, and add Flags to the
options structures we pass into those methods. In create() methods,
make copies of those passed-in options structures before modifying any
of their contents.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
improve the heuristic to detect the user namespace size needed to run
an image. Hardcode the nobody user value to 65534, which is the value
used by the kernel, and ignore this value when parsing /etc/passwd and
/etc/group.
Closes: https://github.com/containers/storage/issues/1472
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Instead of reading that value, releasing the mount lock,
and then unmounting, provide a "conditional" unmount mode.
And use that in the existing "loop unmounting" code.
That's at least safer against concurrent processes unmounting
the same layer. But the callers that try to "really unmount"
the layer in a loop are still possibly racing against other processes
trying to mount the layer in the meantime.
I'm not quite sure that we need the "conditional" parameter as an
explicit choice; it seems fairly likely that Umount() should just fail
with ErrLayerNotMounted for all !force callers. I chose to use the flag
to be conservative WRT possible unknown constraints.
Similarly, it's not very clear to me that the unmount loops need to exist;
maybe they should just be unmount(force=true, conditional=true).
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Using `%q` as format specifier for size prints non-meaningful error
messages instead use `%v` which will print in default format.
Example Bad error message
```console
Error: identifier is not a container: preparing container for next step:
creating build container: creating container: the container needs a user
namespace with size '𘛋' that is bigger than the maximum value allowed
with userns=auto '𐀀''
```
Signed-off-by: Aditya R <arajan@redhat.com>
- imageTopLayerForMapping, in the cParentLayer loop, was reading all
additional layer stores, although only some of them might have been
locked at that point.
- getAutoUserNS -> getMaxSizeFromImage was assuming that all layer stores
are locked, but in fact the additional layer stores were all unlocked
at that point
- getMaxSizeFromImage was calling store.getLayerStore() and the like,
which could potentially trigger a reload via graphLock and return
a _different_ store than the one that was locked
So, lock _all_ layer stores in CreateContainer (at least on the path
where images are involved), and pass the locked layer stores down the
call stack.
Also, document a bit more explicitly what's going on.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
It is not directly reachable by any public API, and there are no known
external users.
So, make it obviously private to make it easier to change the returned
interface in the future.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... to reduce duplication of read implementations of Store.
This can almost certainly be simplified further; this is enough
for the purposes of this PR, where we want to decrease the
number of callers that need to be updated.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Use constants for the names of flags that we set in Flags maps that we
store in layer/image/container records, to make it easier to avoid
possible breakages due to typos in the future.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
We now use the golang error wrapping format specifier `%w` instead of the
deprecated github.com/pkg/errors package.
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
There isn't any easy-to-see reason to use the same ID for
the two objects, and not needing to known the container ID
at that point will help generating it correctly without
breaking the ContainerStore abstraction.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This implements the algorithm proposed in
https://github.com/containers/storage/issues/852#issuecomment-798954173,
which is:
1. find available IDs from subuid/subgid file; by subtracting the used
IDs (from other containers) as well as additional IDs, we get the IDs
available to allocate;
2. target ID range is [0, requestedSize), subtract the additional IDs;
3. allocate IDs from range in step 1; the number to allocate is the
number of IDs in step 2;
4. generate a mapping from IDs in step 3 to the ones in step 2.
Closes: https://github.com/containers/storage/issues/852
Signed-off-by: Kan Li <likan@google.com>
Currently when we build podman bindings we are pulling in the entire
storage libraries, even though we only need a few structures and
functions.
Testing with the following program
```
package main
import (
"fmt"
"github.com/containers/storage/types"
)
func main() {
fmt.Println(types.GetRootlessRuntimeDir(0))
}
```
Removing types above gives me compile size of the the program
du -s t.old t.new
9640 t.before
3232 t.after
Currently these functions are being vendored into
containers/common/pkg/config, which leads to large size in podman-remote
and podman bindings.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
The logic of range subtraction [a,b)-[c,d) can be viewed as intersection
of [a,b) with (-inf, c) and [d, +inf), respectively. This makes the
logic simpler, that we no longer need to check 5 different cases.
It also fixes bugs that returns incorrect range.
Closes#763
Signed-off-by: Kan Li <likan@google.com>
when an explicit idmapping is specified, the host id must be taken
from the available range of IDs.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
automatically pick an empty range and create an user namespace for the
container.
For root containers, it is necessary to specify an entry in
the /etc/subuid and /etc/subgid files to use for picking the range of
available IDs. This is necessary to avoid collisions with IDs used
for rootless containers. This setting is ignored for rootless
containers, since it is not possible to use arbitrary IDs, and the
initial set is always picked by the IDs assigned to the rootless
user.
When using auto userns, a container will use a range of IDs that is
not used by any other container user namespace, also those that are
not using auto userns, this is checked at creation time.
A successive container that doesn't use auto userns feature can still
collide with IDs used by an auto userns container.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Nalin Dahyabhai