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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This allows snippet generators to explicitly order entries: any string
can be set as an entry's "sort key". If set, sd-boot will use it to sort
entries on display.
New logic is hence (ignore the boot counting logic)
sort-key is set → primary sort key: sort-key (lexicographically increasing order)
→ secondary sort key: machine-id (also increasing order)
→ tertiary sort key: version (lexicographically decreasing order!)
sort-key is not set → primary sort key: entry filename (aka id), lexicographically increasing order)
With this scheme we can order OSes by their names from A-Z but then put
within the same OS still the newest version first. This should clean up
the order to match expectations more.
Based on discussions here:
https://github.com/systemd/systemd/pull/22391#issuecomment-1040092633
We should treat ./some.service and $PWD/some.service as equivalent. But we'd
try to send the relative paths over dbus, which can't work well:
$ sudo systemctl enable ./test2.service
Failed to look up unit file state: Invalid argument
$ sudo systemctl enable $PWD/test2.service
Created symlink /etc/systemd/system/multi-user.target.wants/test2.service → /home/zbyszek/src/systemd/test2.service.
Created symlink /etc/systemd/system/test2.service → /home/zbyszek/src/systemd/test2.service.
Now both are equivalent.
065364920281e1cf59cab989e17aff21790505c4 did the conversion to install_path_printf().
But IIUC, here we are just looking at a unit file name, not the full
path.
Most of the codebase does this. Here we were using 'p' or 'paths'
instead. Those names are very generic and not good for a "global-like"
object like the LookupPaths instance. And we also have 'path' variable,
and it's confusing to have 'path' and 'paths' in the same function that
are unrelated.
Also pass down LookupPaths* lower in the call stack, in preparation for
future changes.
If people use nspawn in their $HOME we should allow this inodes owned by
this special UID to be created temporarily, so that UID mapped nspawn
containers just work.
When using user namespaces in conjunction with uidmapped mounts, nspawn
so far set up two uidmappings:
1. One that is used for the uidmapped mount and that maps the UID range
0…65535 on the backing fs to some high UID range X…X+65535 on the
uidmapped fs. (Let's call this mapping the "mount mapping")
2. One that is used for the userns namespace the container payload
processes run in, that maps X…X+65535 back to 0…65535. (Let's call
this one the "process mapping").
These mappings hence are pretty much identical, one just moves things up
and one back down. (Reminder: we do all this so that the processes can
run under high UIDs while running off file systems that require no
recursive chown()ing, i.e. we want processes with high UID range but
files with low UID range.)
This creates one problem, i.e. issue #20989: if nspawn (which runs as
host root, i.e. host UID 0) wants to add inodes to the uidmapped mount
it can't do that, since host UID 0 is not defined in the mount mapping
(only the X…X+65536 range is, after all, and X > 0), and processes whose
UID is not mapped in a uidmapped fs cannot create inodes in it since
those would be owned by an unmapped UID, which then triggers
the famous EOVERFLOW error.
Let's fix this, by explicitly including an entry for the host UID 0 in
the mount mapping. Specifically, we'll extend the mount mapping to map
UID 2147483646 (which is INT32_MAX-1, see code for an explanation why I
picked this one) of the backing fs to UID 0 on the uidmapped fs. This
way nspawn can creates inode on the uidmapped as it likes (which will
then actually be owned by UID 2147483646 on the backing fs), and as it
always did. Note that we do *not* create a similar entry in the process
mapping. Thus any files created by nspawn that way (and not chown()ed to
something better) will appear as unmapped (i.e. as overflowuid/"nobody")
in the container payload. And that's good. Of course, the latter is
mostly theoretic, as nspawn should generally chown() the inodes it
creates to UID ranges that actually make sense for the container (and we
generally already do this correctly), but it#s good to know that we are
safe here, given we might accidentally forget to chown() some inodes we
create.
Net effect: the two mappings will not be identical anymore. The mount
mapping has one entry more, and the only reason it exists is so that
nspawn can access the uidmapped fs reasonably independently from any
process mapping.
Fixes: #20989
And enable cgroup delegation for udevd.
Then, processes invoked through ExecReload= are assigned .control
subcgroup, and they are not killed by cg_kill().
Fixes#16867 and #22686.
varlink_error(...) expects a json object as the third parameter. Passing a string variant causes
parameter sanitization to fail, and it returns -EINVAL. Pass object variant instead.
