FLAGS_SET() checks if *all* the bits are set. In this case we want to check
if *any* are. FLAGS_SET() was added in cde2f8605e0c3842f9a87785dd758f955f2d04ba,
but not a bug then yet, because with just one bit, both options are equivalent.
But when more bits were added later, this stopped being correct.
Fixup for cde2f8605e0c3842f9a87785dd758f955f2d04ba. Use PIN+PV because the
status quo ante was that we turned off "uv" and left "up" and "clientPin" in
its default values, which with yubikeys (i.e. the most popular hardware) meant
both "up" and "clientPin" were enabled by default.
Lucas Magasweran [Mon, 10 May 2021 08:11:28 +0000 (10:11 +0200)]
man: network: use `networkctl list` instead of `status` to list network interface type
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.
Roman Beranek [Fri, 30 Apr 2021 13:51:44 +0000 (15:51 +0200)]
resolve: remove RRs from zones before an update
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.
nss-systemd: synthesize NSS shadow/gshadow records from userdb, as well
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.
nss-systemd: set USERDB_SUPPRESS_SHADOW flag when looking up user records
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.
mount-util: add a helper that can add an idmap to an existing mount
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.
nspawn: replace boolean --private-user-chown by enum
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.
nspawn: add high-level option for identity userns mapping
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.)
FIDO2: ask and record whether user verification was used to lock the volume
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.
FIDO2: ask and record whether user presence was used to lock the volume
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.
cryptsetup: add 'headless' parameter to skip password/pin query
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.
userdbd: simplify logic for generating NSS listings
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.
Yu Watanabe [Fri, 7 May 2021 19:13:12 +0000 (04:13 +0900)]
string-util: fix build error on aarch64
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
```
userdbd: reverse which path is a socket and which a symlink
userdbd listens on "two" sockets, that are actually the same: one is a
real AF_UNIX socket in the fs, and the other is a symlink to it.
So far, when userdbd was started from the command line it would make one
a symlink and the other a real socket, but when invoked via unit files
they'd be swapped, i.e. the other would be a symlink and the one a real
socket.
Let's bring this in line.
Since the "io.systemd.Multiplexer" is our main interface, let's make it
the one exposed as socket, and then make "io.systemd.NameServiceSwitch"
a symlink to it. Or in other words, let's adjust the C code to match the
unit file.
Add SBAT support, when -Dsbat-distro value is specified. One can use
-Dsbat-distro=auto for autodetection of all sbat options. Many meson configure
options added to customize SBAT CSV values, but sensible defaults are auto
detected by default. SBAT support is required if shim v15+ is used to load
systemd-boot binary or kernel.efi (Type II BootLoaderSpec).
When we are queried for membership lists on a system that has exactly
zero, then we'll return ESRCH immediately instead of at EOF. Which is
OK, but we need to handle this in various places, and not get confused
by it.
user-util: add generic definition for special password hash values in /etc/passwd + /etc/shadow
Let's add three defines for the 3 special cases of passwords.
Some of our tools used different values for the "locked"/"invalid" case,
let's settle on using "!*" which means the password is both locked *and*
invalid.
Other tools like to use "!!" for this case, which however is less than
ideal I think, since the this could also be a considered an entry with
an empty password, that can be enabled again by unlocking it twice.
howl [Tue, 4 May 2021 09:20:23 +0000 (11:20 +0200)]
Unify pn81H3 and cvrLenovoideapadD330-10IGM
D330-10IGM has been added due the fact that 81H3 and 81MD product name belongs to the same product version. So the fact is that now that we know 81MD has the same transformation matrix that the 81H3 we can just use the product version and get rid the product name.
Signed-off-by: David Santamaría Rogado <howl.nsp@gmail.com>
If ":" was the last char in the string, we would call access() on ".../drivers/", which
would pass. It probably doesn't matter, but let's reject this anyway.
Not only we would duplicate unknown input on the stack, we would do it
over and over. So let's first check that the input has reasonable length,
but also allocate just one fixed size buffer.
The ID_FFADO environment variable comes from external FFADO project.
Now we have comprehensive and self-contained rules instead of it.
Let's remove it.
hwdb: ieee1394-unit-function: add entry for AV/C device with vendor unique command set
In IEC 61883-1:1998, we can see some values for AV/C device with vendor
unique command set in IEC 61883-1:1998. Current udev rule handles it
for video. However it brings an issue that the functions in AV/C device
are not distinguished just by the content of configuration ROM.
In former commit, hardware database was added to describe function type
of unit in the node, then udev rules are added to utilize the database.
However, we have an request to obsolete existent udev rules by putting
enough entries to the database. It should be done carefully.
This commit adds entry into hardware database just for backward
compatibility. The entry can match to some node and unit unexpectedly.
Therefore this commit modifies existent entries to invalidate the effect
from added entry.
hwdb: ieee1394-unit-function: add entry for AV/C device with generic AV/C command set
Typical node of AV/C device has standard content of configuration ROM.
This is defined in documentation of 1394 Trading Association.
* Configuration ROM for AV/C Devices 1.0 (Dec. 12, 2000, 1394 Trading
Association, TA Document 1999027)
However, it brings an issue that the functions in AV/C device are not
distinguished just by the content of configuration ROM.
In former commit, hardware database was added to describe function type
of unit in the node, then udev rules are added to utilize the database.
However, we have an request to obsolete existent udev rules by putting
enough entries to the database. It should be done carefully.
This commit adds entry into hardware database just for backward
compatibility. The entry can match to some node and unit unexpectedly.
Therefore this commit modifies existent entries to invalidate the effect
from added entry.
hwdb: ieee1394-unit-function: remove entry for Cool Stream iSweet
IIDC specification describes configuration ROM without model field, thus
it's not possible to match any entry with vendor ID and model ID.
Current entry for Cool Stream iSweet can match any node and unit of
IIDC.
This commit removes the entry. I note that this model uses Texus
Instruments MC680-DCC as all-in-one chipset for video function in
IEEE 1394 bus.
hwdb: ieee1394-unit-function: add entries for Point Grey cameras
Point Grey Research, inc. shipped cameras to support IIDC, however some
of them are necessarily compliant to IIDC specification in terms of the
value of software version field in unit directory of configuration ROM.
Instrumentation & Industrial Digital Camera (IIDC) specifications are
defined by 1394 Trading Association for camera device in IEEE 1394 bus.
IIDC2 specifications are defined by joint working group between Japan
Industrial Imaging Association (JIIA) and 1394 Trade Association as
bus-independent specification.
This commit adds entries for the specifications to remove existent udev
rules. Supported specifications are listed below:
* 1394-based Digital Camera Specification Version 1.04 (Aug. 9, 1996,
1394 Trading Association)
* 1394-based Digital Camera Specification Version 1.20 (Jul. 23, 1998,
1394 Trading Association)
* IIDC Digital Camera Control Specification Ver.1.30 (Jul. 25, 2000,
1394 Trading Association)
* IIDC Digital Camera Control Specification Ver.1.31 (Feb. 2, 2004,
1394 Trading Association, TA Document 2003017)
* IIDC Digital Camera Control Specification Ver.1.32 (Jul. 24, 2008,
1394 Trading Association, Document number 2007009)
* IIDC2 Digital Camera Control Specification Ver.1.0.0 (Jan 26th, 2012,
1394 Trading Association, TS2011001)
* IIDC2 Digital Camera Control Specification Ver.1.1.0 (May 19th, 2015,
1394 Trading Association, TS2015001)
hwdb: ieee1394-unit-function: add entries for Digital Everywhere FloppyDTV and FireDTV
Linux kernel has firedtv kernel module as driver for Digital Everywhere
FloppyDTV and FireDTV. Although this driver works without any help of
userspace application, it's better to add entries to hardware database
for developer's convenience.
Zbigniew Jędrzejewski-Szmek points that current entries are against the
convention of indentation. It should be indented by one space instead of
two.
This commit fixes current entries according to it.
Reported-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> Fixes: 1b6d9a05b14a ("hwdb: add database entries for models with ASICs in BeBoB solution") Fixes: 0db0564e957f ("hwdb: add database entries for models with Fireworks board module") Fixes: 38338b302cb0 ("hwdb: add database entries for models with OXFW970/971 ASICs") Fixes: c0d8b61f9385 ("hwdb: add database entries for models based on DICE ASICs with TCAT specification") Fixes: a774b5099bce ("hwdb: add database entries for models based on DICE ASICs specialized to M-Audio") Fixes: ff1cb7b9393a ("hwdb: add database entries for models based on DICE ASICs specialized to Weiss Engineering") Fixes: 6f44dddbe20a ("hwdb: add database entries for models based on DICE ASICs specialized by Loud Technologies") Fixes: 49ed0aad525b ("hwdb: add database entries for models based on DICE ASICs specialized by Harman Music Group") Fixes: effbb4024b8b ("hwdb: add database entries for models based on DICE ASICs specialized by Solid State Logic") Fixes: 4aaa093b5fb6 ("hwdb: add database entries for models of Digidesign Digi 00x family") Fixes: c489e7f9d3c4 ("hwdb: add database entries for Tascam FireWire series") Fixes: 650b8967a57b ("hwdb: add database entries for MOTU FireWire series") Fixes: 51e9242b9b91 ("hwdb: add database entries for RME Fireface series") Fixes: a90a6a9ae9f8 ("hwdb: add database entries for Yamaha mLAN 2nd generation") Fixes: 41f2d0d393a4 ("hwdb: add database entries for Yamaha mLAN 3rd generation") Fixes: 1d2ee962922f ("hwdb: add database entries for Focusrite Liquid Mix series") Fixes: 0c20543835d6 ("hwdb: add database entries for TC Electronic PowerCore FireWire series") Fixes: 8b4b76dc5021 ("hwdb: add database entry for node with single unit with video function") Fixes: 12dd2404bee8 ("hwdb: add database entries for node with multiple units") Fixes: dece0357e1c8 ("hwdb: add database entries for node with single unit for multiple functions") Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
hwdb: fix parser to execute test for ieee1394-unit-function with no argument
When given no arguments, hwdb parser script seeks test target files by
glob pattern. Although I added a new file for IEEE 1394 unit functions,
the file is excluded as test target due to the pattern.
This commit fixes it.
Fixes: 7713f3fc6a2 ("hwdb: add parser grammar for IEEE 1394 unit function list") Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
projects / thirdparty / systemd.git / log
