| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
FORK_DEATHSIG_SIGTERM
Sometimes it makes sense to hard kill a client if we die. Let's hence
add a third FORK_DEATHSIG flag for this purpose: FORK_DEATHSIG_SIGKILL.
To make things less confusing this also renames FORK_DEATHSIG to
FORK_DEATHSIG_SIGTERM to make clear it sends SIGTERM. We already had
FORK_DEATHSIG_SIGINT, hence this makes things nicely symmetric.
A bunch of users are switched over for FORK_DEATHSIG_SIGKILL where we
know it's safe to abort things abruptly. This should make some kernel
cases more robust, since we cannot get confused by signal masks or such.
While we are at it, also fix a bunch of bugs where we didn't take
FORK_DEATHSIG_SIGINT into account in safe_fork()
|
|
|
|
|
|
| |
Let's a "b" helper for json_variant_set_field() that combines
json_build() with json_variant_set_field(), similar to the
json_variant_merge_objectb(), json_variant_append_arrayb().
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
json_append() is a useful wrapper around json_variant_merge(). However,
I think the naming sould be cleaned up a bit of both functions.
I thinker "merge" is the better word than "append", since it does
decidedly more than just append: it replaces existing fields of the same
name, hence "merge" sounds more appropriate. This is as opposed to the
similar operations for arrays, where no such override logic is applied
and we really just append, hence those functions are called "append"
already.
To make clearer that "merge" is about objects, and "append" about
arrays, also include "object" in the name.
Also, include "json_variant" in the name, like we do for almost all
other functions in the JSON API that take a JSON object as primary
input, and hence are kinda object methods.
Finally, let's follow the logic that helpers that combine json_build()
with some other operation get suffixed with "b" like we already have in
some cases.
Hence:
json_variant_merge() → json_variant_merge_object()
json_append() → json_variant_merge_objectb()
This mirrors nicely the existing:
json_variant_append_array()
json_vairant_append_arrayb()
This also drops the variant of json_append() that takes a va_arg
parameter (i.e. json_appendv()). We have no user of that so far, and
given the nature as a helper function only I don#t see that happening,
and if it happens after all it's trivial to bring back.
|
|
|
|
|
|
| |
pwquality and passwdqc
Co-authored-by: Dmitry V. Levin <ldv@altlinux.org>
|
|
|
|
| |
Instead of _cleanup_(set_freep) or so.
|
|
|
|
|
| |
parse_boolean_argument() returns the same information via both the output
argument and normal return.
|
|
|
|
|
|
|
|
|
|
|
|
| |
In various tools and services we have a per-system and per-user concept.
So far we sometimes used a boolean indicating whether we are in system
mode, or a reversed boolean indicating whether we are in user mode, or
the LookupScope enum used by the lookup path logic.
Let's address that, in introduce a common enum for this, we can use all
across the board.
This is mostly just search/replace, no actual code changes.
|
| |
|
| |
|
|
|
|
|
|
| |
Let's allow users to configure the (logical) sector size of their
image. This is required when building images for a 4k sector size
disk on a 512b sector size host or vice-versa.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-1 was used everywhere, but -EBADF or -EBADFD started being used in various
places. Let's make things consistent in the new style.
Note that there are two candidates:
EBADF 9 Bad file descriptor
EBADFD 77 File descriptor in bad state
Since we're initializating the fd, we're just assigning a value that means
"no fd yet", so it's just a bad file descriptor, and the first errno fits
better. If instead we had a valid file descriptor that became invalid because
of some operation or state change, the other errno would fit better.
In some places, initialization is dropped if unnecessary.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
* Some authenticators(like Yubikey) support credential algorithm other than ES256
* Introduce a new option so users can make use of it
|
|
|
|
|
|
|
|
|
|
|
| |
Same idea as 03677889f0ef42cdc534bf3b31265a054b20a354.
No functional change intended. The type of the iterator is generally changed to
be 'const char*' instead of 'char*'. Despite the type commonly used, modifying
the string was not allowed.
I adjusted the naming of some short variables for clarity and reduced the scope
of some variable declarations in code that was being touched anyway.
|
|
|
|
| |
This also avoids multiple evaluations in STRV_FOREACH_BACKWARDS()
|
|
|
|
|
|
|
|
| |
The new helper combines a bunch of steps every invocation of
unsetenv_erase() did so far: getenv() + strdup() + unsetenv_erase().
Let's unify this into one helper that is harder to use incorrectly. It's
in inspired by TAKE_PTR() in a way: get the env var out and invalidate
where it was before.
|
|
|
|
| |
The ratelimit hits even when the all previous attempts are successfull.
|
|
|
|
|
| |
Let's add an explicit, synchronous command to request immediate rebalancing and
wait for it.
|
| |
|
|
|
|
|
|
|
|
|
| |
In 57bb9bcba5563c040ee0c41f58e3730a006a8de2 support was added to read
"cheap" passwords from env vars and stuff before issuing the first
operation, instead of waiting for it until the first operation failed.
This was added for most verbs of "homectl", but two were left out:
update + passwd. Add it there too.
|
| |
|
| |
|
|\
| |
| | |
Use double and int64_t types in json
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We were already asserting that the intmax_t and uintmax_t types
are the same as int64_t and uint64_t. Pretty much everywhere in
the code base we use the latter types. In principle intmax_t could
be something different on some new architecture, and then the code would
fail to compile or behave differently. We actually do not want the code
to behave differently on those architectures, because that'd break
interoperability. So let's just use int64_t/uint64_t since that's what
we indend to use.
|
|/
|
|
|
|
| |
for it
Fixes: #21103
|
|
|
|
|
|
|
|
| |
user-record.[ch] are about the UserRecord JSON stuff, and the UID
allocation range stuff (i.e. login.defs handling) is a very different
thing, and complex enough on its own, let's give it its own c/h files.
No code changes, just some splitting out of code.
|
| |
|
|\
| |
| | |
A coding style tweak and checking of sd_notify() calls and voidification of pager_open()
|
| | |
|
|/
|
|
|
|
|
|
| |
(Or when -H is used, since -H and -M are incompatible.)
Note that the slightly unusual form with separate boolean variables (hint_vars,
hint_addr) instead of e.g. a const char* variable to hold the message, because this
way we don't trigger the warning about non-literal format.
|
|
|
|
|
|
|
|
| |
backend
This is useful since certain shares can only be mounted with additional
mount flags. For example the SMB share in modern AVM Fritz!Boxes
requires "noserverino" to be set to work from Linux.
|
| |
|
|
|
|
| |
Fixes: #20857
|
|
|
|
|
|
|
|
| |
glyph-util.[ch]
These functions are used pretty much independently of locale, i.e. the
only info relevant is whether th locale is UTF-8 or not. Hence let's
give this its own pair of .c/.h files.
|
| |
|
|
|
|
| |
Let's unify how we remove secrets from the env block.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In general we almost never hit those asserts in production code, so users see
them very rarely, if ever. But either way, we just need something that users
can pass to the developers.
We have quite a few of those asserts, and some have fairly nice messages, but
many are like "WTF?" or "???" or "unexpected something". The error that is
printed includes the file location, and function name. In almost all functions
there's at most one assert, so the function name alone is enough to identify
the failure for a developer. So we don't get much extra from the message, and
we might just as well drop them.
Dropping them makes our code a tiny bit smaller, and most importantly, improves
development experience by making it easy to insert such an assert in the code
without thinking how to phrase the argument.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want user records to be extensible, hence we shouldn't complain about
fields we can't parse. In particular we want them to be extensible for
our own future extensions.
Some code already turned the permissive flag when parsing the JSON data,
but most did not. Fix that. A few select cases remain where the bit is
not set: where we just gnerated the JSON data ourselves, and thus can be
reasonably sure that if we can't parse it it's our immediate programming
error and not just us processing a user record from some other tool or a
newer version of ourselves.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This catches up homed's FIDO2 support with cryptsetup's: we'll now store
the uv/up/clientPin configuration at enrollment in the user record JSON
data, and use it when authenticating with it.
This also adds explicit "uv" support: we'll only allow it to happen when
the client explicity said it's OK. This is then used by clients to print
a nice message suggesting "uv" has to take place before retrying
allowing it this time. This is modelled after the existing handling for
"up".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
first request
Previously, we'd generally attempt the operation first, without any
passwords, and only query for a password if that operation then fails
and asks for one. This is done to improve compatibility with
password-less authentication schemes, such as security tokens and
similar.
This patch modifies this slightly: if a password can be acquired cheaply
via the keyring password cache, the $CREDENTIALS_PATH credential store,
or the $PASSWORD/$PIN environment variables, acquire it *before* issuing
the first requested.
This should save us a pointless roundtrip, and should never hurt.
|
| |
|
|
|
|
|
|
| |
Asking repeatedly for a password is pointless if we always use the same
cached one. Let's thus disable cache use whenever we failed already
once.
|
|
|
|
|
| |
The usual: the test wasn't testing, so we didn't notice that the
command wasn't returning as expected.
|
|
|
|
|
|
|
|
|
|
|
|
| |
store first
This adds generic support for the SetCredential=/LoadCredential= logic
to our password querying infrastructure: if a password is requested by a
program that has a credential store configured via
$CREDENTIALS_DIRECTORY we'll look in it for a password.
The "systemd-ask-password" tool is updated with an option to specify the
credential to look for.
|
| |
|
| |
|