Drop CAP_{NET_ADMIN,SYS_PTRACE} from the default capabilities which
are only needed to run bwrap from inside a stage which is done by
the `ostree.commit` and `ostree.preptree` stages, so retain them
directly there.
Add new stage metadata `CAPABILITIES` where stages can request
additional capabilities that are not in the default set.
Currently this is not used by any stage since the default set
contains the sum of all needed capabilities.
Drop all capabilities that are not required by any of the stages.
N.B. at least one stage (`ostree.preptree`) itself executes bwrap
itself, which in turn needs `CAP_SYS_PTRACE` and `CAP_NET_ADMIN`.
Add a new member variable `caps` that if not `None` indicates the
capabilities to retain, i.e. all other capabilities not specified
will be dropped via `bubblewrap` (`--cap-drop`).
Add corresponding tests.
LVM2 introduced system.devices as an alternative way to filter
devices. Since we create devices in a stage the devices won't be
added to the /etc/lvm/devices/system.devices file since /etc/ is
inside the container. As a result the we can't see these devices
and will fail with "Could not find parent device".
Therefore we add support for managing our own per-service devices
file, iff a `system.devices` is present.
This extends the possible ways of passing references to inputs. The
current ways possible are:
1) "plain references", an array of strings:
["ref1", "ref2", ...]
2) "object references", a mapping of keys to objects:
{"ref1": { <options> }, "ref2": { <options> }, ...}
This patch adds a new way:
3) "array of object references":
[{"id": "ref1", "options": { ... }}, {"id": ... }, ]
While osbuild promises to preserves the order for "object references"
not all JSON serialization libraries preserve the order since the
JSON specification does leave this up to the implementation.
The new "array of object references" thus allows for specifying the
references together with reference specific options and this in a
specific order.
Additionally this paves the way for specifying the same input twice,
e.g. in the case of the `org.osbuild.files` input where a pipeline
could then be specified twice with different files. This needs core
rework though, since internally we use dictionaries right now.
Specifically this test checks that the order given in the manifest is
preserved when loaded, i.e. the internal dict has the keys ordered in
the same way, independently in which way they were specified -- list
or object.
When using "plain refs", that is, when using an array of strings,
we did not enforce the constraints of exactly one reference. This
was done for dictionary references.
This is a left-over from the time when `systemd-nspawn` was used,
which only retained a limited set of capabilities which did not
include `CAP_MAC_ADMIN`[1]. Bubblewrap, on the other hand, retains
all currently capabilities if the process is run as root[2].
[1] see e.g. src/nspawn/nspawn.c#L147 of commit c52950c
[2] see commit abc56644566a6095bb72a5bf70fcee7dd90e9447
mkfs.xfs already has `additionalProperties: true` for the devices
section, as this is necessary for example when creating lvm2 setups.
This should be possible for other filesystem types too.
The unit test consists of a manifest creating an empty file, which
is then converted to various formats using the `org.osbuild.qemu` stage
in separate pipelines.
The unit test then builds and exports each pipeline with qemu stage and
inspects the resulting image file using `qemu-img info` command and checks
that the test data specified in `checks.json` is a subset of the data
returned by the command.
When is specified change the GPT partition attribute bits. The attributes
is a comma list of bits numbers or bit names. You can take a look at the
manual page of sfdisk to see the supported attribute bits.
Instead of a human pushing a tag with the release notes let a bot do the
work.
The bot is part of our composite action in osbuild/release-action on the
create-tag branch. It calculates the next subsequent release version and
creates a tag based on pull request titles associated with the changes
since the last release.
Finally the tag is pushed to the repository.
Unfortunately GH Actions don't allow for reliably fortnightly schedules,
so we do an additional check that determines if this is an even or an
odd week. This will help with correctly scheduling alternating osbuild
and osbuild-composer releases.
For reference, we do exactly the same for osbuild-composer already:
https://github.com/osbuild/osbuild-composer/blob/main/.github/workflows/create-tag.yml
If instructed, the rpm stage checks all digests and signatures of a package
explicitly using `rpmkeys` tool. The default stage behavior is that no
package signatures are checked when installed by the stage (not even
explicitly).
For these reasons, the package signature checking is supposed to be
disabled when installing rpm packages. This was achieved by passing the
`--define "_pkgverify_level none"` option to rpm. However this option
specifies only requirements for a package to be installed and `none`
means that packages without any signature are accepted by rpm. If the
package signature is deemed BAD, the package installation fails even
though this option has been passed to rpm.
There are valid cases when even packages which signature marked as BAD
should be installed. It may happen, that the GPG key used to sign a
package uses an algorithm not allowed by the system crypto policy, e.g.
SHA1. If such GPG key is imported on the system and a package signed
using it is being installed, its installation would fail when the
package is read by rpm. This is because its signatures are by default
checked if they exist in the package.
The desired behavior to not check any package signatures when installing
a package is instead achieved by using `--nosignature` rpm option. It
turns off the whole signature checking mechanism.
Use the `--nosignature` rpm option instead of
`--define "_pkgverify_level none"`, when installing packages using rpm.
Fix https://github.com/osbuild/osbuild/issues/991
Instead of using `chcon`, directly call `selinux.setfilecon`.
On systems without SELinux support, i.e. coreutils was built
without `<selinux.h>` present, `chcon` will return `ENOTSUP`
for all calls to SElinux functions like `setfilecon` even if
the selinux libraries are later installed.
Therefore we directly call the new osbuild helper function,
which really is just a wrapper around setting extended file
attributes and thus will work even if SELinux support is not
compiled into coreutils.
The only other thing `chcon` is doing besides a cal to the
`setfilecon` method is to convert the context string to a
new `contex_t` and back to validate it. This should not be
needed since the kernel will do this for us. On system
without SELinux support `context_new` will also not validate
the context.
This is basically a re-implementation of `setfilecon(3)` minus the
translation of human readable context to raw context. Add test for
the new function.
Some RPMs might be very large, and limiting the total download time
might lead to failed build even in cases where downloading is making
progress. Instead, set a minimum download speed (1kbps). If the
minimum is not surpassed for 30 seconds in a row, the download fails
and is retried. This follows the logic employed by DNF.
Adjust the number of retries to 10 and the connection timeout to 30,
in order to match what DNF does. One difference is that DNF does 10
retries across all downloads, whereas we do it per download, this
could be changed in a follow-up.
Old:
- a download taking more than 5 minutes is unconditionally aborted
New:
- slow but working downloads will never be aborted
- downloads will be stalled for at most five minutes
in total before being aborted
- time spent making progress does not count towards
the five minutes
Signed-off-by: Tom Gundersen <teg@jklm.no>
Add a new attribute `config.default` that when set will be written to
`GRUB_DEFAULT`. This should be set to `saved` when a `saved_entry` is
specified so that the functionality will be preserved if the grub cfg
gets regenerated (which is really should not, but we can not prohibit
it).
When the firewall stage is provided with stage options, which set only
the default firewall zone, the `firewall-offline-cmd` command is
executed unconditionally without any parameters. This is because in this
case `ports`, `enabled_services` and `disabled_services` are all an
empty lists. This results in a failure with the following error message:
`Opening of '/etc/sysconfig/system-config-firewall' failed, exiting.`
Make sure that the second invocation of `firewall-offline-cmd` happens
conditionally, only when at least one of the `ports`, `enabled_services`
or `disabled_services` is a non-empty list.
Adjust the stage test to cover this scenario.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
In all the invocation of `subprocess.run` stderr and stdout were both
combined in a shared pipe, but lvm sometimes spits out notices and
informational messages on stderr and thus potentially interfering
with the data we are interested in on stdout. Separate the two.
In all invocations of `subprocess.run` stderr and stdout were both
combined in a shared pipe, but lvm sometimes spits out notices and
informational messages on stderr and thus potentially interfering
with the data we are interested in on stdout. Separate the two.
Add a new option `gpgkeys.fromtree` that when specified will
import the specified gpg keys from files located in the tree,
such as `/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release`.
Extend the firewall stage to allow setting the default firewall zone.
Modify the stage unit test accordingly.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
