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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The generic string_hash_ops_free_free hash operations vtable currently
assumes the data pointer is of type char*. There's really no reason to
assume that though, we regularly store non-string data as value in a
hashmap. Hence, to accomodate for that, use void* as pointer for the
value (and keep char* for the key, as that's what
string_hash_ops_free_free is for, after all).
This adds two things:
- A new switch --uuid is added to "udevadm trigger". If specified a
random UUID is associated with the synthettic uevent and it is printed
to stdout. It may then be used manually to match up uevents as they
propagate through the system.
- The UUID logic is now implicitly enabled if "udevadm trigger --settle"
is used, in order to wait for precisely the uevents we actually
trigger. Fallback support is kept for pre-4.13 kernels (where the
requests for trigger uevents with uuids results in EINVAL).
Since kernel 4.13 the kerne allows passing a UUID to generated uevents.
Optionally do so via a new sd_device_trigger_with_uuid() call, and add
sd_device_get_trigger_uuid() as helper to retrieve the UUID from a
uevent we receive.
This is useful for tracking uevents through the udev system, and waiting
for specific triggers.
(Note that the 4.13 patch allows passing arbitrary meta-info into the
uevent as well. This does not add an API for that, because I am not
convinced it makes sense — as it conflicts with our general rule that
events are "stateless" if you so will — and it complicates the interface
quite a bit).
This replaces #13881 in a way, which added a similar infra, but which
stalled, and whose synchronous settling APIs are somewhat problematic
and probably not material to merge.
This is the case because the ID128 we generate are all marked as v4 UUID
which requires that some bits are zero and others are one. Let's
document this so that people can rely on SD_ID128_NULL being a special
value for "uninitialized" that is always distinguishable from generated
UUIDs.
When `NoNewPrivileges=yes`, the service shouldn't have a need for any
setuid/setgid programs, so in case there will be a new mount namespace anyway,
mount the file systems with MS_NOSUID.
The code works differently than the docs, and the code is right here.
Fix the doc hence.
See VALID_CHARS in unit-name.c for details about allowed chars in unit
names, but keep in mind that "-" and "\" are special, since generated by
the escaping logic: they are OK to show up in unit names, but need to be
escaped when converting foreign strings to unit names to make sure
things remain reversible.
Fixes: #19623
Strictly speaking adding this is a compatibility break, given that
previously % weren't special. But I'd argue that was simply a bug, as
for the much more prominent Environment= service setting we always
resolved specifiers, and DEfaultEnvironment= is explicitly listed as
being the default for that. Hence, let's fix that.
Replaces: #16787
This might be useful for CopyFiles=, to reference some subdir of $TMP in
a generic way. This allows us to use the new common
system_and_tmp_specifier_table[].
This moves the definition of the specifier table consisting only of
system and /tmp specifiers into generic code so that we can share it.
This patch only adds one user of it for now. Follow-up patches will add
more.
Otherwise things get very confusing since we mix up netens data from our
client side and from the data we retrieve from networkd.
In the long run we should teach networkctl some switch to operate safely
on other netns, and in that case also determine the right networkd
instance for that namespace.
Fixes: #19236
This is useful for clients to determine whether they are running in the
same network namespace as networkd.
Note that access to /proc/$PID/ns/ is restricted and only permitted to
equally privileged programs. This new bus property is primarily a way to
work around this, so that unprivileged clients can determine the
networkd netns, too.
The comment suggests we validate paths here, but we actually didn't, we
only validated filenames. Let' fix that.
(Note this still lets any kind of paths through, including those with
".." and stuff, this is not a normalization check after all)
Previously, we supported only "," as separator. This adds support for
"+" and makes it the documented choice.
This is to make specifying PCRs in crypttab easier, since commas are
already used there for separating volume options, and needless escaping
sucks.
"," continues to be supported, but in order to keep things minimal not
documented.
Fixe: #19205
When watching paths that contain symlinks in some element we so far
always only watched the inode they are pointing to, not the symlink
inode itself. Let's fix that and always watch both. We do this by simply
installing the inotify watch once with and once without IN_DONT_FOLLOW.
For non-symlink inodes this just overrides the same watch twice (where
the second one replaces the first), which is has no effect effectively.
For symlinks it means we'll watch both source and destination.
Fixes: #17727
