Addresses CVE-2024-1753 which allowed a user to write files to the
`/` directory of the host machine if selinux was not enabled.
Signed-off-by: tomsweeneyredhat <tsweeney@redhat.com>
* Just like buildkit buildah must allow cleaning the buildcache and cache
generated on host by `--mount=type=cache` just like buildkit's `prune`
command.
* Also expose `CleanCacheMount` API so other tools like `podman` can use
it.
See: https://github.com/moby/buildkit#cache
Closes: https://github.com/containers/buildah/issues/4486
Signed-off-by: Aditya R <arajan@redhat.com>
When working with `--mount=type=bind` and `--mount=type=cache` allow
`target` to accept relative paths w.r.t to the configured work dir.
Closes: https://github.com/containers/buildah/issues/4309
Signed-off-by: Aditya R <arajan@redhat.com>
`mount=type=cache` creates a common cache directory on host in temporary
directory, split this cache directory for each user invocation in order
to prevent overlapping of cache content when `buildah` is invoked by
different users on same host.
Signed-off-by: Aditya R <arajan@redhat.com>
This allows declaring run mounts using e.g. '-mount=type=nullfs,...' on
FreeBSD which makes more sense for FreeBSD users. It is also consistent
with 'podman run' which requires the nullfs mount type on FreeBSD.
[NO NEW TESTS NEEDED]
Signed-off-by: Doug Rabson <dfr@rabson.org>
... and use a more traditional error handling model,
where responsibility for the cleanup passes to the caller
_only_ if the called function succeeds.
To reinforce that, hard-code nil returns on error paths
instead of returning the locks.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
It can return at most one lock, so don't return an array.
Should not change behavior right now, but it will simplify
cleanup.
[NO NEW TESTS NEEDED]
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
They exist in memory anyway, so this is more efficient:
we avoid the need to manually touch the filesystem again,
the associated costs - and the error paths go away.
[NO NEW TESTS NEEDED]
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
`--mount=type=cache` must not add internal lockfiles to cache directory
created by users instead store it in a different central directory with
path as `/base/buildah-cache/buildah-lockfiles`.
There are use-cases where users can wipe cache between the builds so
lockfiles will be removed in unexpected manner and also its not okay to
mix buildah's internal construct with user's cache content.
Helps in: https://github.com/containers/buildah/issues/4342
Signed-off-by: Aditya R <arajan@redhat.com>
Flags processing in `--mount` must not be hardcode to expect first field to
be `type` instead it should be order agnostic.
Closes: https://github.com/containers/podman/issues/15748
Signed-off-by: Aditya R <arajan@redhat.com>
`--mount=type=cache` is buildah's internal construct and actual location
is not managed by user so enable `z` by default is `SELinux` is enabled
on the host machine, instead of asking users to do it.
Signed-off-by: Aditya R <arajan@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>
As builds got more complicated, the ability to only access files from one location became quite limiting. With `multi-stage` builds where you can `copy` files from other parts of the Containerfile by adding the `--from` flag and pointing it to the name of another Containerfile stage or a remote image.
The new named build context feature is an extension of this pattern. You can now define additional build contexts when running the build command, give them a name, and then access them inside a Dockerfile the same way you previously did with build stages.
Additional build contexts can be defined with a new `--build-context [name]=[value]` flag. The key component defines the name for your build context and the value can be:
```console
Local directory – e.g. --build-context project2=../path/to/project2/src
HTTP URL to a tarball – e.g. --build-context src=https://example.org/releases/src.tar
Container image – Define with a docker-image:// prefix, e.g. --build-context alpine=docker-image://alpine:3.15, ( also supports docker://, container-image:// )
```
On the Containerfile side, you can reference the build context on all commands that accept the “from” parameter. Here’s how that might look:
```Dockerfile
FROM [name]
COPY --from=[name] ...
RUN --mount=from=[name] …
```
The value of [name] is matched with the following priority order:
* Named build context defined with `--build-context [name]=..`
* Stage defined with `AS [name]` inside Dockerfile
* Remote image `[name]` in a container registry
Added Features
* Pinning images for `FROM` and `COPY`
* Specifying multiple buildcontexts from different projects
and using them with `--from` in `ADD` and `COPY` directive
* Override a Remote Dependency with a Local One.
* Using additional context from external `Tar`
Signed-off-by: Aditya R <arajan@redhat.com>
When a test needs to talk to a registry server, launch one as part of
the test rather than depending on it having been started by someone
else.
Use run_buildah where we used to use 'run buildah' without checking the
return code, and in a few cases where we did check it.
In the "from with non buildah container" test, use "podman create" with
host networking, in an attempt to avoid messing with networking in cases
where we're running on a system with a version of podman that will
create a bridge with CNI that we'll also create with netavark. We're
not sharing storage between the two invocations, so the logic that tries
to detect this problem won't detect it.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Implementation of `GetVolumes` seems to be changing with addition of new
features hence moving it from exposed parse package to internal parse
package and move needed helpers with it.
Signed-off-by: Aditya R <arajan@redhat.com>
A shared cache on host must support locking so other parallel/concurrent builds
will wait for current executing RUN statement to finish.
* Locks the cache store as soon as RUN is triggered.
* Locked target is added to cleanup list so it can be unlocked as soon
as RUN step is completed.
Signed-off-by: Aditya R <arajan@redhat.com>
Stage mounting was not functionl for systems with `selinux` enabled
following commit makes sure we enable it and removes temporary
workaround/hack which was preventing to do it.
Signed-off-by: Aditya Rajan <arajan@redhat.com>
Following commit adds buildkit like support for `from` field to `--mount=type=bind`
and `--mount=type=cache` so images and stage can be used as mount source.
Usage looks like
```dockerfile
RUN --mount=type=bind,source=.,from=<your-image>,target=/path ls /path
```
and
```dockerfile
RUN --mount=type=cache,from=<your-image>,target=/path ls /path
```
Signed-off-by: Aditya Rajan <arajan@redhat.com>
tomsweeneyredhat
Aditya R
Miloslav Trmač
Doug Rabson
Sascha Grunert
Nalin Dahyabhai
Daniel J Walsh