This beefs up the READ_FULL_FILE_CONNECT_SOCKET logic of
read_full_file_full() a bit: when used a sender socket name may be
specified. If specified as NULL behaviour is as before: the client
socket name is picked by the kernel. But if specified as non-NULL the
client can pick a socket name to use when connecting. This is useful to
communicate a minimal amount of metainformation from client to server,
outside of the transport payload.
Specifically, these beefs up the service credential logic to pass an
abstract AF_UNIX socket name as client socket name when connecting via
READ_FULL_FILE_CONNECT_SOCKET, that includes the requesting unit name
and the eventual credential name. This allows servers implementing the
trivial credential socket logic to distinguish clients: via a simple
getpeername() it can be determined which unit is requesting a
credential, and which credential specifically.
Example: with this patch in place, in a unit file "waldo.service" a
configuration line like the following:
LoadCredential=foo:/run/quux/creds.sock
will result in a connection to the AF_UNIX socket /run/quux/creds.sock,
originating from an abstract namespace AF_UNIX socket:
@$RANDOM/unit/waldo.service/foo
(The $RANDOM is replaced by some randomized string. This is included in
the socket name order to avoid namespace squatting issues: the abstract
socket namespace is open to unprivileged users after all, and care needs
to be taken not to use guessable names)
The services listening on the /run/quux/creds.sock socket may thus
easily retrieve the name of the unit the credential is requested for
plus the credential name, via a simpler getpeername(), discarding the
random preifx and the /unit/ string.
This logic uses "/" as separator between the fields, since both unit
names and credential names appear in the file system, and thus are
designed to use "/" as outer separators. Given that it's a good safe
choice to use as separators here, too avoid any conflicts.
This is a minimal patch only: the new logic is used only for the unit
file credential logic. For other places where we use
READ_FULL_FILE_CONNECT_SOCKET it is probably a good idea to use this
scheme too, but this should be done carefully in later patches, since
the socket names become API that way, and we should determine the right
amount of info to pass over.
This really doesn't matter given that AF_xyz and PF_xyz are equivalent
in all ways, but we almost always use AF_xyz, hence stick to it
universally and convert the remaining PF_ to AF_
Let's use the new flag wherever we read key material/passphrases/hashes
off disk, so that people can plug in their own IPC service as backend if
they like, easily.
(My main goal was actually to support this for crypttab key files — i.e.
that you can specify AF_UNIX sockets as third column in crypttab — but
that's harder to implement, since the keys are read via libcryptsetup's
API, not ours.)
Add support for creating a MACVLAN interface in "source" mode by
specifying Mode=source in the [MACVLAN] section of a .netdev file.
A list of allowed MAC addresses for the corresponding MACVLAN can also
be specified with the SourceMACAddress= option of the [MACVLAN] section.
An example .netdev file:
[NetDev]
Name=macvlan0
Kind=macvlan
MACAddress=02:DE:AD:BE:EF:00
[MACVLAN]
Mode=source
SourceMACAddress=02:AB:AB:AB:AB:01 02:CD:CD:CD:CD:01
SourceMACAddress=02:EF:EF:EF:EF:01
The same keys can also be specified in [MACVTAP] for MACVTAP kinds of
interfaces, with the same semantics.
We would say "ignoring", but invalidate the peer anyway.
Let's only do that if we modified the peer irreperably.
Also add comments explaining allocation handling.
Patch contains a coccinelle script, but it only works in some cases. Many
parts were converted by hand.
Note: I did not fix errors in return value handing. This will be done separate
to keep the patch comprehensible. No functional change is intended in this
patch.
This is a follow-up for 9f83091e3c.
Instead of reading the mtime off the configuration files after reading,
let's do so before reading, but with the fd we read the data from. This
is not only cleaner (as it allows us to save one stat()), but also has
the benefit that we'll detect changes that happen while we read the
files.
This also reworks unit file drop-ins to use the common code for
determining drop-in mtime, instead of reading system clock for that.
```
=220358== Invalid read of size 8
==220358== at 0x452F05: l2tp_session_free (l2tp-tunnel.c:46)
==220358== by 0x456926: l2tp_tunnel_done (l2tp-tunnel.c:725)
==220358== by 0x43CF4D: netdev_free (netdev.c:205)
==220358== by 0x43D045: netdev_unref (netdev.c:210)
==220358== by 0x4198B7: manager_free (networkd-manager.c:1877)
==220358== by 0x40D0B3: manager_freep (networkd-manager.h:105)
==220358== by 0x40DE1C: run (networkd.c:21)
==220358== by 0x40DE75: main (networkd.c:130)
==220358== Address 0x5c035d0 is 0 bytes inside a block of size 40 free'd
==220358== at 0x483A9F5: free (vg_replace_malloc.c:538)
==220358== by 0x452F87: l2tp_session_free (l2tp-tunnel.c:57)
==220358== by 0x456857: netdev_l2tp_tunnel_verify (l2tp-tunnel.c:710)
==220358== by 0x440947: netdev_load_one (netdev.c:738)
==220358== by 0x441222: netdev_load (netdev.c:851)
==220358== by 0x419C50: manager_load_config (networkd-manager.c:1934)
==220358== by 0x40D7BE: run (networkd.c:87)
==220358== by 0x40DE75: main (networkd.c:130)
==220358== Block was alloc'd at
==220358== at 0x4839809: malloc (vg_replace_malloc.c:307)
==220358== by 0x452A76: malloc_multiply (alloc-util.h:96)
==220358== by 0x4531E6: l2tp_session_new_static (l2tp-tunnel.c:82)
==220358== by 0x455C01: config_parse_l2tp_session_id (l2tp-tunnel.c:535)
==220358== by 0x48E6D72: next_assignment (conf-parser.c:133)
==220358== by 0x48E77A3: parse_line (conf-parser.c:271)
==220358== by 0x48E7E4F: config_parse (conf-parser.c:396)
==220358== by 0x48E80E5: config_parse_many_files (conf-parser.c:453)
==220358== by 0x48E8490: config_parse_many (conf-parser.c:512)
==220358== by 0x44089C: netdev_load_one (netdev.c:729)
==220358== by 0x441222: netdev_load (netdev.c:851)
==220358== by 0x419C50: manager_load_config (networkd-manager.c:1934)
```
Prompted by the discussions in #15180.
This is a bit more complex than I hoped, since for PID 1 we need to pass
in the synethetic environment block in we generate on demand.
Yu Watanabe