Lennart Poettering d3dcf4e3b9 fileio: beef up READ_FULL_FILE_CONNECT_SOCKET to allow setting sender socket name
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.
2020-11-03 09:48:04 +01:00
2020-11-02 12:41:39 +01:00
2020-10-07 17:12:24 -07:00
2020-10-15 18:01:32 +02:00
2019-04-12 08:30:31 +02:00
2020-09-09 09:34:55 +02:00
2020-07-12 22:00:16 +00:00
2019-04-12 08:30:31 +02:00
2020-10-26 20:43:18 +01:00
2020-08-19 10:18:33 +02:00
2020-10-06 13:59:52 +02:00
2020-11-02 15:30:16 +01:00

Systemd

System and Service Manager

Count of open issues over time Count of open pull requests over time Semaphore CI Build Status
Coverity Scan Status
OSS-Fuzz Status
CIFuzz
CII Best Practices
Travis CI Build Status
Language Grade: C/C++
CentOS CI - CentOS 7
CentOS CI - Arch
CentOS CI - Arch (sanitizers)
Build Status
Fossies codespell report
Packaging status

Details

Most documentation is available on systemd's web site.

Assorted, older, general information about systemd can be found in the systemd Wiki.

Information about build requirements is provided in the README file.

Consult our NEWS file for information about what's new in the most recent systemd versions.

Please see the Hacking guide for information on how to hack on systemd and test your modifications.

Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.

When preparing patches for systemd, please follow our Coding Style Guidelines.

If you are looking for support, please contact our mailing list or join our IRC channel.

Stable branches with backported patches are available in the stable repo.

Description
No description provided
Readme 238 MiB
Languages
C 88.9%
Python 5.4%
Shell 4.3%
Meson 1.2%