IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We actually already have this logic in run(), that under
various conditions uses a different root fs to operate on. No need to do
this twice.
(Or to say this in stronger words: this is dead code, because run()
aleady moved the root fs to something else if it sees "/" being used.
When running unprivileged containers, we run into a scenario where an
unpriv owned cgroup has a subcgroup delegated to another user (i.e. the
container's own UIDs). When the owner of that cgroup dies without
cleaning it up then the unpriv service manager might encounter a cgroup
it cannot delete anymore.
Let's address that: let's expose a method call on the service manager
(primarly in PID1) that can be used to delete a subcgroup of a unit one
owns. This would then allow the unpriv service manager to ask the priv
service manager to get rid of such a cgroup.
This commit only adds the method call, the next commit then adds the
code that makes use of this.
Given that systemd-dissect can nowadays operate on plain directories,
let's include directory images in the --discover output too.
Replace the filter with a filter for hidden images instead, as suddenly
the root fs image (which is a directory image ".host") otherwise shows up.
Note that we have to drop various sandboxing knobs from the mountfsd
service file for this to work, since the kernel's security checks that
try to ensure than an obstructued /proc/ cannot be circumvented via
mounting a new procfs will otherwise prohibit mountfsd to duplicate the
mounts properly.
This makes the UID range configurable via build time options, but of
course it really shouldn't be changed. The default range I picked is
outside even of IPAs current (ridiculously large) allocation ranges,
hence hopefully minimizes conflicts.
Let's optionally mangle any passed name on the server side so that it is
useful for identifying a userns, if it isn't suitable for that
right-away. This mostl means truncating it if too long.
It's just too nasty to leave this to the client side, since they'd have
to understand the precise rules for naming userns then.
While we are at it, add full Varlink IDL comments.
Let's implement the spec more comprehensively.
This is piece by piece work, There's more to do on the EFI side before
all CHID types are supported, but in userspace it should be reasonably
complete now.
Let's use "mkosi sandbox" in the docs so that users can build systemd
without having to install anything except mkosi. Using mkosi sandbox
will use tools and dependencies from the tools tree which is also used
in CI and thus has a higher chance of working from the first try compared
to whatever tools might be installed on the host system of a new contributor.
Building systemd with mkosi generally requires a very recent version
of systemd which might not be installed on the host. Let's configure
mkosi to look for extra executables in the build/ directory by default
so that we prefer systemd executables from the build directory over those
on the host as those on the host are likely to be too old.
Let's enable usage of a tools tree by default to simplify the setup
for new contributors and save them from having to install or upgrade
a bunch of extra tools to get mkosi working as expected.
We need packages from EPEL to be able to build CentOS Stream images
with a CentOS Stream tools tree so enable it. This is broken on CentOS
Stream 10 but given using a CentOS Stream tools tree is broken without
EPEL as well, we might as well enable it and just wait until the packages
are added to EPEL 10.
This add he missing CHID types to our tables, but doesn't add all
necessary code to calculate them yet.
This brings us closer to what the CHID spec documents, and what
"fupwdtool hwids" outputs.
Some of the field names between kernel and smbios spec differ. Kinda
confusing. Let's use the smbios field names, to match the CHID spec,
which also uses them, and thus be least confusing, treating kernel
attribute fields as an internal Linux thing only.
