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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
To determine the network interface type for use in the `Type=` directive, it is more concise to use the `list` command. Whereas, the `status` command requires an interface parameter.
For example, on a RaspberryPi 4 the following shows that the `wlan0` interface type `wlan` is more coveniently listed by the `list` command.
```
root@raspberrypi4-64:~# networkctl list
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 eth0 ether routable configured
3 wlan0 wlan off unmanaged
3 links listed.
```
Whereas the `networkctl status` command doesn't include this information.
```
root@raspberrypi4-64:~# networkctl status
● State: routable
Address: 192.168.1.141 on eth0
fd8b:8779:b7a4::f43 on eth0
fd8b:8779:b7a4:0:dea6:32ff:febe:d1ce on eth0
fe80::dea6:32ff:febe:d1ce on eth0
Gateway: 192.168.1.1 (CZ.NIC, z.s.p.o.) on eth0
DNS: 192.168.1.1
May 07 14:17:18 raspberrypi4-64 systemd-networkd[212]: eth0: Gained carrier
May 07 14:17:19 raspberrypi4-64 systemd-networkd[212]: eth0: Gained IPv6LL
May 07 14:17:19 raspberrypi4-64 systemd-networkd[212]: eth0: DHCPv6 address fd8b:8779:b7a4::f43/128 timeout preferred -1 valid -1
May 07 14:17:21 raspberrypi4-64 systemd-networkd[212]: eth0: DHCPv4 address 192.168.1.141/24 via 192.168.1.1
```
To get the interface type using the `status` command you need to specify an additional argument.
```
root@raspberrypi4-64:~# networkctl status wlan0
● 3: wlan0
Link File: /lib/systemd/network/99-default.link
Network File: n/a
Type: wlan
State: off (unmanaged)
Path: platform-fe300000.mmcnr
Driver: brcmfmac
HW Address: dc:a6:32:be:d1:cf (Raspberry Pi Trading Ltd)
MTU: 1500 (min: 68, max: 1500)
QDisc: noop
IPv6 Address Generation Mode: eui64
Queue Length (Tx/Rx): 1/1
```
During an update of RRs, the records of each DNS-SD service are
replaced with new ones. However the old RRs can only be removed from
the mDNS scopes as long as they remain accessible from the DnssdService
structures, otherwise they remain stuck there.
Therefore the removal must take place before the update.
This ensures we not only synthesize regular paswd/group records of
userdb records, but shadow records as well. This should make sure that
userdb can be used as comprehensive superset of the classic
passwd/group/shadow/gshadow functionality.
Setting the flags means we won#t try to read the data from /etc/shadow
when reading a user record, thus slightly making conversion quicker and
reducing the chance of generating MAC faults, because we needlessly
access a privileged resource. Previously, passing the flag didn't
matter, when converting our JSON records to NSS since the flag only had
an effect on whether to use NSS getspnam() and related calls or not. But
given that we turn off NSS anyway as backend for this conversion (since
we want to avoid NSS loops, where we turn NSS data to our JSON user
records, and then to NSS forever and ever) it was unnecessary to pass
it.
This changed in one of the previous commits however, where we added
support for reading user definitions from drop-in files, with separate
drop-in files for the shadow data.
This adds a two new values to --private-users-ownership=: "map" and
"auto".
"map" exposes the kernel 5.12 idmap feature pretty much 1:1. It fails if
the kernel or used file system doesn't support ID mapping.
"auto" is a bit smarter: if we can make ID mapping work, we'll use it,
otherwise revert back to classic chown()ing. We'll also use chown()ing
if we detect that an image is already ID shifted, both to increase
compatibility with the status quo ante, and to simplify our codepaths,
since the mappings become a lot simpler if we only have to map from zero
to something else, instead of from anything to anything else.
The short -U switch, and --private-users=pick will now imply
--private-users-ownership=auto instead of
--private-users-ownership=chown, since the new logic should be the much
better choice.
This makes use of the new kernel 5.12 APIs to add an idmap to a mount
point. It does so by cloning the mountpoint, changing it, and then
unmounting the old mountpoint, replacing it later with the new one.
This replaces --private-user-chown by an enum value
--private-user-ownership=off|chown. Changes otherwise very little.
This is mostly preparation for a follow-up commit adding a new "map"
mode, using kernel 5.12 UID mapping mounts.
Note that this does alter codeflow a bit: the new enum already knows
three different values instead of the old true/false pair. Besides "off"
and "chown" it knows -EINVAL, i.e. whenever the value wsn't set
explicitly. This value is changed to "off" or "chown" before use, thus
retaining compat to the status quo before, except it won't override
explicit configuration anymore. Thus, if you explicitly request
--private-user=pick you can now combine it wiht an explicit
--private-user-ownership=off if you like, which will give you a
container that runs under its own UID set, but the files will be owned
by the original image. Makes not much sense besids maybe debugging, but
if requested explicitly I think it's OK to implement.
userns identity 1:1 mapping is a pretty useful concept since it isolates
capability sets between containers and hosts, even if it doesn't map
any uid ranges. Let's support it with an explicit concept.
(Note that this is identical to --private-users=0:65536 (which in turn
is identical to --private-users=0), but I think it makes to emphasize
this concept as a high-level one that makes sense to support.)
Some tokens support authorization via fingerprint or other biometric
ID. Add support for "user verification" to cryptenroll and cryptsetup.
Disable by default, as it is still quite uncommon.
In some cases user presence might not be required to get _a_
secret out of a FIDO2 device, but it might be required to
the get actual secret that was used to lock the volume.
Record whether we used it in the LUKS header JSON metadata.
Let the cryptenroll user ask for the feature, but bail out if it is
required by the token and the user disabled it.
Enabled by default.
Closes: https://github.com/systemd/systemd/issues/19246
Some FIDO2 devices allow the user to choose whether to use a PIN or not
and will HMAC with a different secret depending on the choice.
Some other devices (or some device-specific configuration) can instead
make it mandatory.
Allow the cryptenroll user to choose whether to use a PIN or not, but
fail immediately if it is a hard requirement.
Record the choice in the JSON-encoded LUKS header metadata so that the
right set of options can be used on unlock.
On headless setups, in case other methods fail, asking for a password/pin
is not useful as there are no users on the terminal, and generates
unwanted noise. Add a parameter to /etc/crypttab to skip it.
So far we basically had two ways to iterate through NSS records: one via
the varlink IPC and one via the userdb.[ch] infra, with slightly
different implementations.
Let's clean this up, and always use userdb.[ch] also when resolving via
userdbd. The different codepaths for the NameServiceSwitch and the
Multiplexer varlink service now differ only in the different flags
passed to the userdb lookup.
Behaviour shouldn't change by this. This is mostly refactoring, reducing
redundant codepaths.
Let's use "exclude" for flags that really exclude records from our
lookup. Let's use "avoid" referring to concepts that when flag is set
we'll not use but we have a fallback path for that should yield the same
result. Let' use "suppress" for suppressing partial info, even if we
return the record otherwise.
So far we used "avoid" for all these cases, which was confusing.
Whiel we are at it, let's reassign the bits a bit, leaving some space
for bits follow-up commits are going to add.
This fixes the following error:
```
In file included from ../src/basic/af-list.h:6,
from ../src/basic/af-list.c:7:
../src/basic/string-util.h: In function 'char_is_cc':
../src/basic/string-util.h:133:19: error: comparison is always true due to limited range of data type [-Werror=type-limits]
133 | return (p >= 0 && p < ' ') || p == 127;
| ^~
cc1: all warnings being treated as errors
```
Fixes#19543.
