passt: Relicense to GPL 2.0, or any later version
In practical terms, passt doesn't benefit from the additional
protection offered by the AGPL over the GPL, because it's not
suitable to be executed over a computer network.
Further, restricting the distribution under the version 3 of the GPL
wouldn't provide any practical advantage either, as long as the passt
codebase is concerned, and might cause unnecessary compatibility
dilemmas.
Change licensing terms to the GNU General Public License Version 2,
or any later version, with written permission from all current and
past contributors, namely: myself, David Gibson, Laine Stump, Andrea
Bolognani, Paul Holzinger, Richard W.M. Jones, Chris Kuhn, Florian
Weimer, Giuseppe Scrivano, Stefan Hajnoczi, and Vasiliy Ulyanov.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-04-05 20:11:44 +02:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2021-08-12 15:42:43 +02:00
|
|
|
|
|
|
|
/* PASST - Plug A Simple Socket Transport
|
|
|
|
* for qemu/UNIX domain socket mode
|
|
|
|
*
|
|
|
|
* PASTA - Pack A Subtle Tap Abstraction
|
|
|
|
* for network namespace/tap device mode
|
|
|
|
*
|
|
|
|
* conf.c - Configuration settings and option parsing
|
|
|
|
*
|
|
|
|
* Copyright (c) 2020-2021 Red Hat GmbH
|
|
|
|
* Author: Stefano Brivio <sbrivio@redhat.com>
|
|
|
|
*/
|
|
|
|
|
2021-10-21 04:26:08 +02:00
|
|
|
#include <arpa/inet.h>
|
|
|
|
#include <errno.h>
|
|
|
|
#include <fcntl.h>
|
2021-08-12 15:42:43 +02:00
|
|
|
#include <getopt.h>
|
|
|
|
#include <string.h>
|
2021-10-21 04:26:08 +02:00
|
|
|
#include <sched.h>
|
2021-08-12 15:42:43 +02:00
|
|
|
#include <sys/types.h>
|
|
|
|
#include <sys/stat.h>
|
|
|
|
#include <limits.h>
|
2022-05-18 19:10:45 +02:00
|
|
|
#include <grp.h>
|
|
|
|
#include <pwd.h>
|
2023-03-21 04:54:59 +01:00
|
|
|
#include <unistd.h>
|
2023-03-08 04:00:22 +01:00
|
|
|
#include <signal.h>
|
2021-08-12 15:42:43 +02:00
|
|
|
#include <stdlib.h>
|
|
|
|
#include <stdint.h>
|
2023-03-08 04:00:22 +01:00
|
|
|
#include <stdio.h>
|
2022-07-22 07:31:16 +02:00
|
|
|
#include <stdbool.h>
|
2021-08-12 15:42:43 +02:00
|
|
|
#include <syslog.h>
|
|
|
|
#include <time.h>
|
|
|
|
#include <netinet/in.h>
|
2021-10-21 04:26:08 +02:00
|
|
|
#include <netinet/if_ether.h>
|
|
|
|
|
2021-08-12 15:42:43 +02:00
|
|
|
#include "util.h"
|
2024-03-06 06:58:33 +01:00
|
|
|
#include "ip.h"
|
2021-08-12 15:42:43 +02:00
|
|
|
#include "passt.h"
|
2021-10-21 04:26:08 +02:00
|
|
|
#include "netlink.h"
|
2024-05-22 20:18:19 +02:00
|
|
|
#include "tap.h"
|
2021-08-12 15:42:43 +02:00
|
|
|
#include "udp.h"
|
|
|
|
#include "tcp.h"
|
2021-10-11 12:01:31 +02:00
|
|
|
#include "pasta.h"
|
2022-06-24 04:17:30 +02:00
|
|
|
#include "lineread.h"
|
2022-09-12 14:24:03 +02:00
|
|
|
#include "isolation.h"
|
2022-09-24 09:53:15 +02:00
|
|
|
#include "log.h"
|
2021-08-12 15:42:43 +02:00
|
|
|
|
2022-09-28 06:33:12 +02:00
|
|
|
/**
|
|
|
|
* next_chunk - Return the next piece of a string delimited by a character
|
|
|
|
* @s: String to search
|
|
|
|
* @c: Delimiter character
|
|
|
|
*
|
2022-11-17 06:58:38 +01:00
|
|
|
* Return: If another @c is found in @s, returns a pointer to the
|
|
|
|
* character *after* the delimiter, if no further @c is in @s,
|
|
|
|
* return NULL
|
2022-09-28 06:33:12 +02:00
|
|
|
*/
|
|
|
|
static char *next_chunk(const char *s, char c)
|
|
|
|
{
|
|
|
|
char *sep = strchr(s, c);
|
|
|
|
return sep ? sep + 1 : NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* port_range - Represents a non-empty range of ports
|
|
|
|
* @first: First port number in the range
|
|
|
|
* @last: Last port number in the range (inclusive)
|
|
|
|
*
|
|
|
|
* Invariant: @last >= @first
|
|
|
|
*/
|
|
|
|
struct port_range {
|
|
|
|
in_port_t first, last;
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* parse_port_range() - Parse a range of port numbers '<first>[-<last>]'
|
|
|
|
* @s: String to parse
|
|
|
|
* @endptr: Update to the character after the parsed range (similar to
|
|
|
|
* strtol() etc.)
|
|
|
|
* @range: Update with the parsed values on success
|
|
|
|
*
|
|
|
|
* Return: -EINVAL on parsing error, -ERANGE on out of range port
|
|
|
|
* numbers, 0 on success
|
|
|
|
*/
|
|
|
|
static int parse_port_range(const char *s, char **endptr,
|
|
|
|
struct port_range *range)
|
|
|
|
{
|
|
|
|
unsigned long first, last;
|
|
|
|
|
|
|
|
last = first = strtoul(s, endptr, 10);
|
|
|
|
if (*endptr == s) /* Parsed nothing */
|
|
|
|
return -EINVAL;
|
|
|
|
if (**endptr == '-') { /* we have a last value too */
|
|
|
|
const char *lasts = *endptr + 1;
|
|
|
|
last = strtoul(lasts, endptr, 10);
|
|
|
|
if (*endptr == lasts) /* Parsed nothing */
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((last < first) || (last >= NUM_PORTS))
|
|
|
|
return -ERANGE;
|
|
|
|
|
|
|
|
range->first = first;
|
|
|
|
range->last = last;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2022-05-01 06:36:34 +02:00
|
|
|
/**
|
|
|
|
* conf_ports() - Parse port configuration options, initialise UDP/TCP sockets
|
|
|
|
* @c: Execution context
|
|
|
|
* @optname: Short option name, t, T, u, or U
|
|
|
|
* @optarg: Option argument (port specification)
|
2024-02-28 12:25:20 +01:00
|
|
|
* @fwd: Pointer to @fwd_ports to be updated
|
2022-05-01 06:36:34 +02:00
|
|
|
*/
|
2023-02-15 09:24:32 +01:00
|
|
|
static void conf_ports(const struct ctx *c, char optname, const char *optarg,
|
2024-02-28 12:25:20 +01:00
|
|
|
struct fwd_ports *fwd)
|
2021-08-12 15:42:43 +02:00
|
|
|
{
|
2022-07-13 08:05:01 +02:00
|
|
|
char addr_buf[sizeof(struct in6_addr)] = { 0 }, *addr = addr_buf;
|
2022-10-07 04:53:40 +02:00
|
|
|
char buf[BUFSIZ], *spec, *ifname = NULL, *p;
|
2023-02-16 01:29:55 +01:00
|
|
|
bool exclude_only = true, bound_one = false;
|
2022-09-24 11:08:16 +02:00
|
|
|
uint8_t exclude[PORT_BITMAP_SIZE] = { 0 };
|
2022-05-01 06:36:34 +02:00
|
|
|
sa_family_t af = AF_UNSPEC;
|
conf, passt.1: Exit if we can't bind a forwarded port, except for -[tu] all
...or similar, that is, if only excluded ranges are given (implying
we'll forward any other available port). In that case, we'll usually
forward large sets of ports, and it might be inconvenient for the
user to skip excluding single ports that are already taken.
The existing behaviour, that is, exiting only if we fail to bind all
the ports for one given forwarding option, turns out to be
problematic for several aspects raised by Paul:
- Podman merges ranges anyway, so we might fail to bind all the ports
from a specific range given by the user, but we'll not fail anyway
because Podman merges it with another one where we succeed to bind
at least one port. At the same time, there should be no semantic
difference between multiple ranges given by a single option and
multiple ranges given as multiple options: it's unexpected and
not documented
- the user might actually rely on a given port to be forwarded to a
given container or a virtual machine, and if connections are
forwarded to an unrelated process, this might raise security
concerns
- given that we can try and fail to bind multiple ports before
exiting (in case we can't bind any), we don't have a specific error
code we can return to the user, so we don't give the user helpful
indication as to why we couldn't bind ports.
Exit as soon as we fail to create or bind a socket for a given
forwarded port, and report the actual error.
Keep the current behaviour, however, in case the user wants to
forward all the (available) ports for a given protocol, or all the
ports with excluded ranges only. There, it's more reasonable that
the user is expecting partial failures, and it's probably convenient
that we continue with the ports we could forward.
Update the manual page to reflect the new behaviour, and the old
behaviour too in the cases where we keep it.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Link: https://github.com/containers/podman/pull/21563#issuecomment-1937024642
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Tested-by: Paul Holzinger <pholzing@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2024-02-14 02:26:24 +01:00
|
|
|
unsigned i;
|
2023-03-08 13:21:19 +01:00
|
|
|
int ret;
|
2021-08-12 15:42:43 +02:00
|
|
|
|
|
|
|
if (!strcmp(optarg, "none")) {
|
2022-09-24 11:08:20 +02:00
|
|
|
if (fwd->mode)
|
2023-02-15 09:24:32 +01:00
|
|
|
goto mode_conflict;
|
|
|
|
|
2022-09-24 11:08:20 +02:00
|
|
|
fwd->mode = FWD_NONE;
|
2023-02-15 09:24:32 +01:00
|
|
|
return;
|
2021-08-12 15:42:43 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!strcmp(optarg, "auto")) {
|
2023-02-15 09:24:32 +01:00
|
|
|
if (fwd->mode)
|
|
|
|
goto mode_conflict;
|
|
|
|
|
|
|
|
if (c->mode != MODE_PASTA)
|
|
|
|
die("'auto' port forwarding is only allowed for pasta");
|
|
|
|
|
2022-09-24 11:08:20 +02:00
|
|
|
fwd->mode = FWD_AUTO;
|
2023-02-15 09:24:32 +01:00
|
|
|
return;
|
2021-08-12 15:42:43 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!strcmp(optarg, "all")) {
|
2023-02-15 09:24:32 +01:00
|
|
|
if (fwd->mode)
|
|
|
|
goto mode_conflict;
|
|
|
|
|
2024-06-13 14:36:53 +02:00
|
|
|
if (c->mode == MODE_PASTA)
|
2023-02-15 09:24:32 +01:00
|
|
|
die("'all' port forwarding is only allowed for passt");
|
|
|
|
|
2022-09-24 11:08:20 +02:00
|
|
|
fwd->mode = FWD_ALL;
|
|
|
|
memset(fwd->map, 0xff, PORT_EPHEMERAL_MIN / 8);
|
2022-05-01 06:36:34 +02:00
|
|
|
|
|
|
|
for (i = 0; i < PORT_EPHEMERAL_MIN; i++) {
|
2023-02-16 01:29:55 +01:00
|
|
|
if (optname == 't') {
|
2023-03-08 13:21:19 +01:00
|
|
|
ret = tcp_sock_init(c, AF_UNSPEC, NULL, NULL,
|
|
|
|
i);
|
|
|
|
if (ret == -ENFILE || ret == -EMFILE)
|
|
|
|
goto enfile;
|
|
|
|
if (!ret)
|
2023-02-16 01:29:55 +01:00
|
|
|
bound_one = true;
|
|
|
|
} else if (optname == 'u') {
|
2023-03-08 13:21:19 +01:00
|
|
|
ret = udp_sock_init(c, 0, AF_UNSPEC, NULL, NULL,
|
|
|
|
i);
|
|
|
|
if (ret == -ENFILE || ret == -EMFILE)
|
|
|
|
goto enfile;
|
|
|
|
if (!ret)
|
2023-02-16 01:29:55 +01:00
|
|
|
bound_one = true;
|
|
|
|
}
|
2022-05-01 06:36:34 +02:00
|
|
|
}
|
|
|
|
|
2023-02-16 01:29:55 +01:00
|
|
|
if (!bound_one)
|
conf, passt.1: Exit if we can't bind a forwarded port, except for -[tu] all
...or similar, that is, if only excluded ranges are given (implying
we'll forward any other available port). In that case, we'll usually
forward large sets of ports, and it might be inconvenient for the
user to skip excluding single ports that are already taken.
The existing behaviour, that is, exiting only if we fail to bind all
the ports for one given forwarding option, turns out to be
problematic for several aspects raised by Paul:
- Podman merges ranges anyway, so we might fail to bind all the ports
from a specific range given by the user, but we'll not fail anyway
because Podman merges it with another one where we succeed to bind
at least one port. At the same time, there should be no semantic
difference between multiple ranges given by a single option and
multiple ranges given as multiple options: it's unexpected and
not documented
- the user might actually rely on a given port to be forwarded to a
given container or a virtual machine, and if connections are
forwarded to an unrelated process, this might raise security
concerns
- given that we can try and fail to bind multiple ports before
exiting (in case we can't bind any), we don't have a specific error
code we can return to the user, so we don't give the user helpful
indication as to why we couldn't bind ports.
Exit as soon as we fail to create or bind a socket for a given
forwarded port, and report the actual error.
Keep the current behaviour, however, in case the user wants to
forward all the (available) ports for a given protocol, or all the
ports with excluded ranges only. There, it's more reasonable that
the user is expecting partial failures, and it's probably convenient
that we continue with the ports we could forward.
Update the manual page to reflect the new behaviour, and the old
behaviour too in the cases where we keep it.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Link: https://github.com/containers/podman/pull/21563#issuecomment-1937024642
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Tested-by: Paul Holzinger <pholzing@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2024-02-14 02:26:24 +01:00
|
|
|
goto bind_all_fail;
|
2023-02-16 01:29:55 +01:00
|
|
|
|
2023-02-15 09:24:32 +01:00
|
|
|
return;
|
2021-08-12 15:42:43 +02:00
|
|
|
}
|
|
|
|
|
2022-09-24 11:08:20 +02:00
|
|
|
if (fwd->mode > FWD_SPEC)
|
2023-02-15 09:24:32 +01:00
|
|
|
die("Specific ports cannot be specified together with all/none/auto");
|
2021-08-12 15:42:43 +02:00
|
|
|
|
2022-09-24 11:08:20 +02:00
|
|
|
fwd->mode = FWD_SPEC;
|
2021-08-12 15:42:43 +02:00
|
|
|
|
2022-05-01 06:36:34 +02:00
|
|
|
strncpy(buf, optarg, sizeof(buf) - 1);
|
|
|
|
|
2022-07-13 08:05:01 +02:00
|
|
|
if ((spec = strchr(buf, '/'))) {
|
|
|
|
*spec = 0;
|
|
|
|
spec++;
|
2022-05-01 06:36:34 +02:00
|
|
|
|
|
|
|
if (optname != 't' && optname != 'u')
|
|
|
|
goto bad;
|
|
|
|
|
2022-10-07 04:53:40 +02:00
|
|
|
if ((ifname = strchr(buf, '%'))) {
|
|
|
|
*ifname = 0;
|
|
|
|
ifname++;
|
2023-06-28 07:11:15 +02:00
|
|
|
|
|
|
|
/* spec is already advanced one past the '/',
|
|
|
|
* so the length of the given ifname is:
|
|
|
|
* (spec - ifname - 1)
|
|
|
|
*/
|
|
|
|
if (spec - ifname - 1 >= IFNAMSIZ)
|
|
|
|
goto bad;
|
|
|
|
|
2022-10-07 04:53:40 +02:00
|
|
|
}
|
|
|
|
|
2023-03-27 19:35:26 +02:00
|
|
|
if (ifname == buf + 1) /* Interface without address */
|
|
|
|
addr = NULL;
|
|
|
|
else if (inet_pton(AF_INET, buf, addr))
|
2022-05-01 06:36:34 +02:00
|
|
|
af = AF_INET;
|
|
|
|
else if (inet_pton(AF_INET6, buf, addr))
|
|
|
|
af = AF_INET6;
|
|
|
|
else
|
|
|
|
goto bad;
|
|
|
|
} else {
|
2022-07-13 08:05:01 +02:00
|
|
|
spec = buf;
|
2022-05-01 06:36:34 +02:00
|
|
|
|
|
|
|
addr = NULL;
|
2021-08-12 15:42:43 +02:00
|
|
|
}
|
|
|
|
|
2022-07-13 08:05:01 +02:00
|
|
|
/* Mark all exclusions first, they might be given after base ranges */
|
|
|
|
p = spec;
|
2021-08-12 15:42:43 +02:00
|
|
|
do {
|
2022-09-28 06:33:12 +02:00
|
|
|
struct port_range xrange;
|
2022-07-13 08:05:01 +02:00
|
|
|
|
2022-09-28 06:33:12 +02:00
|
|
|
if (*p != '~') {
|
|
|
|
/* Not an exclude range, parse later */
|
|
|
|
exclude_only = false;
|
|
|
|
continue;
|
2022-07-13 08:05:01 +02:00
|
|
|
}
|
conf: Don't pass leading ~ to parse_port_range() on exclusions
Commit 84fec4e998b6 ("Clean up parsing of port ranges") drops the
strspn() call before the parsing of excluded port ranges, because now
we're checking against any stray characters at every step.
However, that also has the effect of passing ~ as first character to
the new parse_port_range(), which makes no sense: we already checked
that ~ is the first character before the call, so skip it.
Alona reported this output:
Invalid port specifier ~15000,~15001,~15006,~15008,~15020,~15021,~15090
while the whole specifier is indeed valid.
Reported-by: Alona Paz <alkaplan@redhat.com>
Fixes: 84fec4e998b6 ("Clean up parsing of port ranges")
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-10-24 14:37:22 +02:00
|
|
|
p++;
|
2022-07-13 08:05:01 +02:00
|
|
|
|
2022-09-28 06:33:12 +02:00
|
|
|
if (parse_port_range(p, &p, &xrange))
|
|
|
|
goto bad;
|
|
|
|
if ((*p != '\0') && (*p != ',')) /* Garbage after the range */
|
2022-07-13 08:05:01 +02:00
|
|
|
goto bad;
|
|
|
|
|
2022-09-28 06:33:12 +02:00
|
|
|
for (i = xrange.first; i <= xrange.last; i++) {
|
|
|
|
if (bitmap_isset(exclude, i))
|
2023-08-11 09:36:00 +02:00
|
|
|
die("Overlapping excluded ranges %s", optarg);
|
2022-07-13 08:05:01 +02:00
|
|
|
|
2022-09-28 06:33:12 +02:00
|
|
|
bitmap_set(exclude, i);
|
2022-07-13 08:05:01 +02:00
|
|
|
}
|
2022-09-28 06:33:12 +02:00
|
|
|
} while ((p = next_chunk(p, ',')));
|
2022-07-13 08:05:01 +02:00
|
|
|
|
|
|
|
if (exclude_only) {
|
|
|
|
for (i = 0; i < PORT_EPHEMERAL_MIN; i++) {
|
|
|
|
if (bitmap_isset(exclude, i))
|
|
|
|
continue;
|
|
|
|
|
2022-09-24 11:08:20 +02:00
|
|
|
bitmap_set(fwd->map, i);
|
2022-07-13 08:05:01 +02:00
|
|
|
|
2023-02-16 01:29:55 +01:00
|
|
|
if (optname == 't') {
|
2023-03-08 13:21:19 +01:00
|
|
|
ret = tcp_sock_init(c, af, addr, ifname, i);
|
|
|
|
if (ret == -ENFILE || ret == -EMFILE)
|
|
|
|
goto enfile;
|
|
|
|
if (!ret)
|
2023-02-16 01:29:55 +01:00
|
|
|
bound_one = true;
|
|
|
|
} else if (optname == 'u') {
|
2023-03-08 13:21:19 +01:00
|
|
|
ret = udp_sock_init(c, 0, af, addr, ifname, i);
|
|
|
|
if (ret == -ENFILE || ret == -EMFILE)
|
|
|
|
goto enfile;
|
|
|
|
if (!ret)
|
2023-02-16 01:29:55 +01:00
|
|
|
bound_one = true;
|
2023-02-16 19:46:36 +01:00
|
|
|
} else {
|
|
|
|
/* No way to check in advance for -T and -U */
|
|
|
|
bound_one = true;
|
2023-02-16 01:29:55 +01:00
|
|
|
}
|
2022-07-13 08:05:01 +02:00
|
|
|
}
|
|
|
|
|
2023-02-16 01:29:55 +01:00
|
|
|
if (!bound_one)
|
conf, passt.1: Exit if we can't bind a forwarded port, except for -[tu] all
...or similar, that is, if only excluded ranges are given (implying
we'll forward any other available port). In that case, we'll usually
forward large sets of ports, and it might be inconvenient for the
user to skip excluding single ports that are already taken.
The existing behaviour, that is, exiting only if we fail to bind all
the ports for one given forwarding option, turns out to be
problematic for several aspects raised by Paul:
- Podman merges ranges anyway, so we might fail to bind all the ports
from a specific range given by the user, but we'll not fail anyway
because Podman merges it with another one where we succeed to bind
at least one port. At the same time, there should be no semantic
difference between multiple ranges given by a single option and
multiple ranges given as multiple options: it's unexpected and
not documented
- the user might actually rely on a given port to be forwarded to a
given container or a virtual machine, and if connections are
forwarded to an unrelated process, this might raise security
concerns
- given that we can try and fail to bind multiple ports before
exiting (in case we can't bind any), we don't have a specific error
code we can return to the user, so we don't give the user helpful
indication as to why we couldn't bind ports.
Exit as soon as we fail to create or bind a socket for a given
forwarded port, and report the actual error.
Keep the current behaviour, however, in case the user wants to
forward all the (available) ports for a given protocol, or all the
ports with excluded ranges only. There, it's more reasonable that
the user is expecting partial failures, and it's probably convenient
that we continue with the ports we could forward.
Update the manual page to reflect the new behaviour, and the old
behaviour too in the cases where we keep it.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Link: https://github.com/containers/podman/pull/21563#issuecomment-1937024642
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Tested-by: Paul Holzinger <pholzing@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2024-02-14 02:26:24 +01:00
|
|
|
goto bind_all_fail;
|
2023-02-16 01:29:55 +01:00
|
|
|
|
2023-02-15 09:24:32 +01:00
|
|
|
return;
|
2022-07-13 08:05:01 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Now process base ranges, skipping exclusions */
|
|
|
|
p = spec;
|
|
|
|
do {
|
2022-09-28 06:33:12 +02:00
|
|
|
struct port_range orig_range, mapped_range;
|
2021-08-12 15:42:43 +02:00
|
|
|
|
2022-09-28 06:33:12 +02:00
|
|
|
if (*p == '~')
|
|
|
|
/* Exclude range, already parsed */
|
|
|
|
continue;
|
2021-08-12 15:42:43 +02:00
|
|
|
|
2022-09-28 06:33:12 +02:00
|
|
|
if (parse_port_range(p, &p, &orig_range))
|
2021-08-12 15:42:43 +02:00
|
|
|
goto bad;
|
|
|
|
|
2022-09-28 06:33:12 +02:00
|
|
|
if (*p == ':') { /* There's a range to map to as well */
|
|
|
|
if (parse_port_range(p + 1, &p, &mapped_range))
|
2021-08-12 15:42:43 +02:00
|
|
|
goto bad;
|
2022-09-28 06:33:12 +02:00
|
|
|
if ((mapped_range.last - mapped_range.first) !=
|
|
|
|
(orig_range.last - orig_range.first))
|
2021-08-12 15:42:43 +02:00
|
|
|
goto bad;
|
2022-09-28 06:33:12 +02:00
|
|
|
} else {
|
|
|
|
mapped_range = orig_range;
|
|
|
|
}
|
2021-08-12 15:42:43 +02:00
|
|
|
|
2022-09-28 06:33:12 +02:00
|
|
|
if ((*p != '\0') && (*p != ',')) /* Garbage after the ranges */
|
|
|
|
goto bad;
|
2021-08-12 15:42:43 +02:00
|
|
|
|
2022-09-28 06:33:12 +02:00
|
|
|
for (i = orig_range.first; i <= orig_range.last; i++) {
|
|
|
|
if (bitmap_isset(fwd->map, i))
|
2023-08-11 09:36:00 +02:00
|
|
|
warn(
|
|
|
|
"Altering mapping of already mapped port number: %s", optarg);
|
2022-07-13 08:05:01 +02:00
|
|
|
|
2022-09-28 06:33:12 +02:00
|
|
|
if (bitmap_isset(exclude, i))
|
|
|
|
continue;
|
2021-08-12 15:42:43 +02:00
|
|
|
|
2022-09-28 06:33:12 +02:00
|
|
|
bitmap_set(fwd->map, i);
|
2021-08-12 15:42:43 +02:00
|
|
|
|
2022-09-28 06:33:12 +02:00
|
|
|
fwd->delta[i] = mapped_range.first - orig_range.first;
|
2021-08-12 15:42:43 +02:00
|
|
|
|
conf, passt.1: Exit if we can't bind a forwarded port, except for -[tu] all
...or similar, that is, if only excluded ranges are given (implying
we'll forward any other available port). In that case, we'll usually
forward large sets of ports, and it might be inconvenient for the
user to skip excluding single ports that are already taken.
The existing behaviour, that is, exiting only if we fail to bind all
the ports for one given forwarding option, turns out to be
problematic for several aspects raised by Paul:
- Podman merges ranges anyway, so we might fail to bind all the ports
from a specific range given by the user, but we'll not fail anyway
because Podman merges it with another one where we succeed to bind
at least one port. At the same time, there should be no semantic
difference between multiple ranges given by a single option and
multiple ranges given as multiple options: it's unexpected and
not documented
- the user might actually rely on a given port to be forwarded to a
given container or a virtual machine, and if connections are
forwarded to an unrelated process, this might raise security
concerns
- given that we can try and fail to bind multiple ports before
exiting (in case we can't bind any), we don't have a specific error
code we can return to the user, so we don't give the user helpful
indication as to why we couldn't bind ports.
Exit as soon as we fail to create or bind a socket for a given
forwarded port, and report the actual error.
Keep the current behaviour, however, in case the user wants to
forward all the (available) ports for a given protocol, or all the
ports with excluded ranges only. There, it's more reasonable that
the user is expecting partial failures, and it's probably convenient
that we continue with the ports we could forward.
Update the manual page to reflect the new behaviour, and the old
behaviour too in the cases where we keep it.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Link: https://github.com/containers/podman/pull/21563#issuecomment-1937024642
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Tested-by: Paul Holzinger <pholzing@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2024-02-14 02:26:24 +01:00
|
|
|
ret = 0;
|
|
|
|
if (optname == 't')
|
2023-03-08 13:21:19 +01:00
|
|
|
ret = tcp_sock_init(c, af, addr, ifname, i);
|
conf, passt.1: Exit if we can't bind a forwarded port, except for -[tu] all
...or similar, that is, if only excluded ranges are given (implying
we'll forward any other available port). In that case, we'll usually
forward large sets of ports, and it might be inconvenient for the
user to skip excluding single ports that are already taken.
The existing behaviour, that is, exiting only if we fail to bind all
the ports for one given forwarding option, turns out to be
problematic for several aspects raised by Paul:
- Podman merges ranges anyway, so we might fail to bind all the ports
from a specific range given by the user, but we'll not fail anyway
because Podman merges it with another one where we succeed to bind
at least one port. At the same time, there should be no semantic
difference between multiple ranges given by a single option and
multiple ranges given as multiple options: it's unexpected and
not documented
- the user might actually rely on a given port to be forwarded to a
given container or a virtual machine, and if connections are
forwarded to an unrelated process, this might raise security
concerns
- given that we can try and fail to bind multiple ports before
exiting (in case we can't bind any), we don't have a specific error
code we can return to the user, so we don't give the user helpful
indication as to why we couldn't bind ports.
Exit as soon as we fail to create or bind a socket for a given
forwarded port, and report the actual error.
Keep the current behaviour, however, in case the user wants to
forward all the (available) ports for a given protocol, or all the
ports with excluded ranges only. There, it's more reasonable that
the user is expecting partial failures, and it's probably convenient
that we continue with the ports we could forward.
Update the manual page to reflect the new behaviour, and the old
behaviour too in the cases where we keep it.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Link: https://github.com/containers/podman/pull/21563#issuecomment-1937024642
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Tested-by: Paul Holzinger <pholzing@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2024-02-14 02:26:24 +01:00
|
|
|
else if (optname == 'u')
|
2023-03-08 13:21:19 +01:00
|
|
|
ret = udp_sock_init(c, 0, af, addr, ifname, i);
|
conf, passt.1: Exit if we can't bind a forwarded port, except for -[tu] all
...or similar, that is, if only excluded ranges are given (implying
we'll forward any other available port). In that case, we'll usually
forward large sets of ports, and it might be inconvenient for the
user to skip excluding single ports that are already taken.
The existing behaviour, that is, exiting only if we fail to bind all
the ports for one given forwarding option, turns out to be
problematic for several aspects raised by Paul:
- Podman merges ranges anyway, so we might fail to bind all the ports
from a specific range given by the user, but we'll not fail anyway
because Podman merges it with another one where we succeed to bind
at least one port. At the same time, there should be no semantic
difference between multiple ranges given by a single option and
multiple ranges given as multiple options: it's unexpected and
not documented
- the user might actually rely on a given port to be forwarded to a
given container or a virtual machine, and if connections are
forwarded to an unrelated process, this might raise security
concerns
- given that we can try and fail to bind multiple ports before
exiting (in case we can't bind any), we don't have a specific error
code we can return to the user, so we don't give the user helpful
indication as to why we couldn't bind ports.
Exit as soon as we fail to create or bind a socket for a given
forwarded port, and report the actual error.
Keep the current behaviour, however, in case the user wants to
forward all the (available) ports for a given protocol, or all the
ports with excluded ranges only. There, it's more reasonable that
the user is expecting partial failures, and it's probably convenient
that we continue with the ports we could forward.
Update the manual page to reflect the new behaviour, and the old
behaviour too in the cases where we keep it.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Link: https://github.com/containers/podman/pull/21563#issuecomment-1937024642
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Tested-by: Paul Holzinger <pholzing@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2024-02-14 02:26:24 +01:00
|
|
|
if (ret)
|
|
|
|
goto bind_fail;
|
2021-08-12 15:42:43 +02:00
|
|
|
}
|
2022-09-28 06:33:12 +02:00
|
|
|
} while ((p = next_chunk(p, ',')));
|
2021-08-12 15:42:43 +02:00
|
|
|
|
2023-02-15 09:24:32 +01:00
|
|
|
return;
|
2023-03-08 13:21:19 +01:00
|
|
|
enfile:
|
|
|
|
die("Can't open enough sockets for port specifier: %s", optarg);
|
2021-08-12 15:42:43 +02:00
|
|
|
bad:
|
2023-02-15 09:24:32 +01:00
|
|
|
die("Invalid port specifier %s", optarg);
|
|
|
|
mode_conflict:
|
|
|
|
die("Port forwarding mode '%s' conflicts with previous mode", optarg);
|
2023-02-16 01:29:55 +01:00
|
|
|
bind_fail:
|
conf, passt.1: Exit if we can't bind a forwarded port, except for -[tu] all
...or similar, that is, if only excluded ranges are given (implying
we'll forward any other available port). In that case, we'll usually
forward large sets of ports, and it might be inconvenient for the
user to skip excluding single ports that are already taken.
The existing behaviour, that is, exiting only if we fail to bind all
the ports for one given forwarding option, turns out to be
problematic for several aspects raised by Paul:
- Podman merges ranges anyway, so we might fail to bind all the ports
from a specific range given by the user, but we'll not fail anyway
because Podman merges it with another one where we succeed to bind
at least one port. At the same time, there should be no semantic
difference between multiple ranges given by a single option and
multiple ranges given as multiple options: it's unexpected and
not documented
- the user might actually rely on a given port to be forwarded to a
given container or a virtual machine, and if connections are
forwarded to an unrelated process, this might raise security
concerns
- given that we can try and fail to bind multiple ports before
exiting (in case we can't bind any), we don't have a specific error
code we can return to the user, so we don't give the user helpful
indication as to why we couldn't bind ports.
Exit as soon as we fail to create or bind a socket for a given
forwarded port, and report the actual error.
Keep the current behaviour, however, in case the user wants to
forward all the (available) ports for a given protocol, or all the
ports with excluded ranges only. There, it's more reasonable that
the user is expecting partial failures, and it's probably convenient
that we continue with the ports we could forward.
Update the manual page to reflect the new behaviour, and the old
behaviour too in the cases where we keep it.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Link: https://github.com/containers/podman/pull/21563#issuecomment-1937024642
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Tested-by: Paul Holzinger <pholzing@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2024-02-14 02:26:24 +01:00
|
|
|
die("Failed to bind port %u (%s) for option '-%c %s', exiting",
|
|
|
|
i, strerror(-ret), optname, optarg);
|
|
|
|
bind_all_fail:
|
2023-02-16 01:29:55 +01:00
|
|
|
die("Failed to bind any port for '-%c %s', exiting", optname, optarg);
|
2021-08-12 15:42:43 +02:00
|
|
|
}
|
|
|
|
|
2023-02-23 14:32:30 +01:00
|
|
|
/**
|
|
|
|
* add_dns4() - Possibly add the IPv4 address of a DNS resolver to configuration
|
|
|
|
* @c: Execution context
|
|
|
|
* @addr: Address found in /etc/resolv.conf
|
|
|
|
* @conf: Pointer to reference of current entry in array of IPv4 resolvers
|
|
|
|
*/
|
2023-09-29 07:50:19 +02:00
|
|
|
static void add_dns4(struct ctx *c, const struct in_addr *addr,
|
|
|
|
struct in_addr **conf)
|
2023-02-23 14:32:30 +01:00
|
|
|
{
|
|
|
|
/* Guest or container can only access local addresses via redirect */
|
|
|
|
if (IN4_IS_ADDR_LOOPBACK(addr)) {
|
|
|
|
if (!c->no_map_gw) {
|
|
|
|
**conf = c->ip4.gw;
|
|
|
|
(*conf)++;
|
conf, udp: Allow any loopback address to be used as resolver
Andrea reports that with a Fedora 37 guest running on a Fedora 37
host, both using systemd-resolved, with passt connecting them,
running with default options, DNS queries don't work.
systemd-resolved on the host is reachable only at the loopback
address 127.0.0.53.
We advertise the default gateway address to the guest as resolver,
because our local address is of course unreachable from there, which
means we see DNS queries directed to the default gateway, and we
redirect them to 127.0.0.1. However, systemd-resolved doesn't answer
on 127.0.0.1.
To fix this, set @dns_match to the address of the default gateway,
unless a different resolver address is explicitly configured, so that
we know we explicitly have to map DNS queries, in this case, to the
address of the local resolver.
This means that in udp_tap_handler() we need to check, first, if
the destination address of packets matches @dns_match: even if it's
the address of the local gateway, we want to map that to a specific
address, which isn't necessarily 127.0.0.1.
Do the same for IPv6 for consistency, even though IPv6 defines a
single loopback address.
Reported-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Tested-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2023-02-23 17:41:47 +01:00
|
|
|
|
|
|
|
if (IN4_IS_ADDR_UNSPECIFIED(&c->ip4.dns_match))
|
|
|
|
c->ip4.dns_match = c->ip4.gw;
|
2023-02-23 14:32:30 +01:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
**conf = *addr;
|
|
|
|
(*conf)++;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (IN4_IS_ADDR_UNSPECIFIED(&c->ip4.dns_host))
|
|
|
|
c->ip4.dns_host = *addr;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* add_dns6() - Possibly add the IPv6 address of a DNS resolver to configuration
|
|
|
|
* @c: Execution context
|
|
|
|
* @addr: Address found in /etc/resolv.conf
|
|
|
|
* @conf: Pointer to reference of current entry in array of IPv6 resolvers
|
|
|
|
*/
|
|
|
|
static void add_dns6(struct ctx *c,
|
|
|
|
struct in6_addr *addr, struct in6_addr **conf)
|
|
|
|
{
|
|
|
|
/* Guest or container can only access local addresses via redirect */
|
|
|
|
if (IN6_IS_ADDR_LOOPBACK(addr)) {
|
|
|
|
if (!c->no_map_gw) {
|
|
|
|
memcpy(*conf, &c->ip6.gw, sizeof(**conf));
|
|
|
|
(*conf)++;
|
conf, udp: Allow any loopback address to be used as resolver
Andrea reports that with a Fedora 37 guest running on a Fedora 37
host, both using systemd-resolved, with passt connecting them,
running with default options, DNS queries don't work.
systemd-resolved on the host is reachable only at the loopback
address 127.0.0.53.
We advertise the default gateway address to the guest as resolver,
because our local address is of course unreachable from there, which
means we see DNS queries directed to the default gateway, and we
redirect them to 127.0.0.1. However, systemd-resolved doesn't answer
on 127.0.0.1.
To fix this, set @dns_match to the address of the default gateway,
unless a different resolver address is explicitly configured, so that
we know we explicitly have to map DNS queries, in this case, to the
address of the local resolver.
This means that in udp_tap_handler() we need to check, first, if
the destination address of packets matches @dns_match: even if it's
the address of the local gateway, we want to map that to a specific
address, which isn't necessarily 127.0.0.1.
Do the same for IPv6 for consistency, even though IPv6 defines a
single loopback address.
Reported-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Tested-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2023-02-23 17:41:47 +01:00
|
|
|
|
|
|
|
if (IN6_IS_ADDR_UNSPECIFIED(&c->ip6.dns_match))
|
|
|
|
memcpy(&c->ip6.dns_match, addr, sizeof(*addr));
|
2023-02-23 14:32:30 +01:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
memcpy(*conf, addr, sizeof(**conf));
|
|
|
|
(*conf)++;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (IN6_IS_ADDR_UNSPECIFIED(&c->ip6.dns_host))
|
|
|
|
c->ip6.dns_host = *addr;
|
|
|
|
}
|
|
|
|
|
2021-08-12 15:42:43 +02:00
|
|
|
/**
|
|
|
|
* get_dns() - Get nameserver addresses from local /etc/resolv.conf
|
|
|
|
* @c: Execution context
|
|
|
|
*/
|
|
|
|
static void get_dns(struct ctx *c)
|
|
|
|
{
|
conf, udp: Drop mostly duplicated dns_send arrays, rename related fields
Given that we use just the first valid DNS resolver address
configured, or read from resolv.conf(5) on the host, to forward DNS
queries to, in case --dns-forward is used, we don't need to duplicate
dns[] to dns_send[]:
- rename dns_send[] back to dns[]: those are the resolvers we
advertise to the guest/container
- for forwarding purposes, instead of dns[], use a single field (for
each protocol version): dns_host
- and rename dns_fwd to dns_match, so that it's clear this is the
address we are matching DNS queries against, to decide if they need
to be forwarded
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2022-11-10 20:30:03 +01:00
|
|
|
struct in6_addr *dns6 = &c->ip6.dns[0], dns6_tmp;
|
|
|
|
struct in_addr *dns4 = &c->ip4.dns[0], dns4_tmp;
|
2021-10-14 01:21:29 +02:00
|
|
|
int dns4_set, dns6_set, dnss_set, dns_set, fd;
|
conf: Split the notions of read DNS addresses and offered ones
With --dns-forward, if the host has a loopback address configured as
DNS server, we should actually use it to forward queries, but, if
--no-map-gw is passed, we shouldn't offer the same address via DHCP,
NDP and DHCPv6, because it's not going to be reachable.
Problematic configuration:
* systemd-resolved configuring the usual 127.0.0.53 on the host: we
read that from /etc/resolv.conf
* --dns-forward specified with an unrelated address, for example
198.51.100.1
We still want to forward queries to 127.0.0.53, if we receive one
directed to 198.51.100.1, so we can't drop 127.0.0.53 from our list:
we want to use it for forwarding. At the same time, we shouldn't
offer 127.0.0.53 to the guest or container either.
With this change, I'm only covering the case of automatically
configured DNS servers from /etc/resolv.conf. We could extend this to
addresses configured with command-line options, but I don't really
see a likely use case at this point.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-11-02 23:52:38 +01:00
|
|
|
struct fqdn *s = c->dns_search;
|
2022-06-24 04:17:30 +02:00
|
|
|
struct lineread resolvconf;
|
conf: Don't warn if nameservers were found, but won't be advertised
Starting from commit 3a2afde87dd1 ("conf, udp: Drop mostly duplicated
dns_send arrays, rename related fields"), we won't add to c->ip4.dns
and c->ip6.dns nameservers that can't be used by the guest or
container, and we won't advertise them.
However, the fact that we don't advertise any nameserver doesn't mean
that we didn't find any, and we should warn only if we couldn't find
any.
This is particularly relevant in case both --dns-forward and
--no-map-gw are passed, and a single loopback address is listed in
/etc/resolv.conf: we'll forward queries directed to the address
specified by --dns-forward to the loopback address we found, we
won't advertise that address, so we shouldn't warn: this is a
perfectly legitimate usage.
Reported-by: Paul Holzinger <pholzing@redhat.com>
Link: https://github.com/containers/podman/issues/19213
Fixes: 3a2afde87dd1 ("conf, udp: Drop mostly duplicated dns_send arrays, rename related fields")
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-03-08 00:12:19 +01:00
|
|
|
unsigned int added = 0;
|
2024-06-06 12:09:48 +02:00
|
|
|
ssize_t line_len;
|
2024-01-15 07:39:43 +01:00
|
|
|
char *line, *end;
|
|
|
|
const char *p;
|
2021-08-12 15:42:43 +02:00
|
|
|
|
2022-11-04 04:10:35 +01:00
|
|
|
dns4_set = !c->ifi4 || !IN4_IS_ADDR_UNSPECIFIED(dns4);
|
2022-07-22 07:31:17 +02:00
|
|
|
dns6_set = !c->ifi6 || !IN6_IS_ADDR_UNSPECIFIED(dns6);
|
2021-08-12 15:42:43 +02:00
|
|
|
dnss_set = !!*s->n || c->no_dns_search;
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
dns_set = (dns4_set && dns6_set) || c->no_dns;
|
2021-08-12 15:42:43 +02:00
|
|
|
|
|
|
|
if (dns_set && dnss_set)
|
|
|
|
return;
|
|
|
|
|
2022-03-27 13:10:26 +02:00
|
|
|
if ((fd = open("/etc/resolv.conf", O_RDONLY | O_CLOEXEC)) < 0)
|
2021-08-12 15:42:43 +02:00
|
|
|
goto out;
|
|
|
|
|
2022-06-24 04:17:30 +02:00
|
|
|
lineread_init(&resolvconf, fd);
|
|
|
|
while ((line_len = lineread_get(&resolvconf, &line)) > 0) {
|
|
|
|
if (!dns_set && strstr(line, "nameserver ") == line) {
|
|
|
|
p = strrchr(line, ' ');
|
2021-08-12 15:42:43 +02:00
|
|
|
if (!p)
|
|
|
|
continue;
|
|
|
|
|
2022-06-24 04:17:30 +02:00
|
|
|
end = strpbrk(line, "%\n");
|
2021-08-12 15:42:43 +02:00
|
|
|
if (end)
|
|
|
|
*end = 0;
|
|
|
|
|
2021-10-10 01:13:37 +02:00
|
|
|
if (!dns4_set &&
|
conf, udp: Drop mostly duplicated dns_send arrays, rename related fields
Given that we use just the first valid DNS resolver address
configured, or read from resolv.conf(5) on the host, to forward DNS
queries to, in case --dns-forward is used, we don't need to duplicate
dns[] to dns_send[]:
- rename dns_send[] back to dns[]: those are the resolvers we
advertise to the guest/container
- for forwarding purposes, instead of dns[], use a single field (for
each protocol version): dns_host
- and rename dns_fwd to dns_match, so that it's clear this is the
address we are matching DNS queries against, to decide if they need
to be forwarded
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2022-11-10 20:30:03 +01:00
|
|
|
dns4 - &c->ip4.dns[0] < ARRAY_SIZE(c->ip4.dns) - 1
|
conf: Don't warn if nameservers were found, but won't be advertised
Starting from commit 3a2afde87dd1 ("conf, udp: Drop mostly duplicated
dns_send arrays, rename related fields"), we won't add to c->ip4.dns
and c->ip6.dns nameservers that can't be used by the guest or
container, and we won't advertise them.
However, the fact that we don't advertise any nameserver doesn't mean
that we didn't find any, and we should warn only if we couldn't find
any.
This is particularly relevant in case both --dns-forward and
--no-map-gw are passed, and a single loopback address is listed in
/etc/resolv.conf: we'll forward queries directed to the address
specified by --dns-forward to the loopback address we found, we
won't advertise that address, so we shouldn't warn: this is a
perfectly legitimate usage.
Reported-by: Paul Holzinger <pholzing@redhat.com>
Link: https://github.com/containers/podman/issues/19213
Fixes: 3a2afde87dd1 ("conf, udp: Drop mostly duplicated dns_send arrays, rename related fields")
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-03-08 00:12:19 +01:00
|
|
|
&& inet_pton(AF_INET, p + 1, &dns4_tmp)) {
|
2023-02-23 14:32:30 +01:00
|
|
|
add_dns4(c, &dns4_tmp, &dns4);
|
conf: Don't warn if nameservers were found, but won't be advertised
Starting from commit 3a2afde87dd1 ("conf, udp: Drop mostly duplicated
dns_send arrays, rename related fields"), we won't add to c->ip4.dns
and c->ip6.dns nameservers that can't be used by the guest or
container, and we won't advertise them.
However, the fact that we don't advertise any nameserver doesn't mean
that we didn't find any, and we should warn only if we couldn't find
any.
This is particularly relevant in case both --dns-forward and
--no-map-gw are passed, and a single loopback address is listed in
/etc/resolv.conf: we'll forward queries directed to the address
specified by --dns-forward to the loopback address we found, we
won't advertise that address, so we shouldn't warn: this is a
perfectly legitimate usage.
Reported-by: Paul Holzinger <pholzing@redhat.com>
Link: https://github.com/containers/podman/issues/19213
Fixes: 3a2afde87dd1 ("conf, udp: Drop mostly duplicated dns_send arrays, rename related fields")
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-03-08 00:12:19 +01:00
|
|
|
added++;
|
|
|
|
}
|
2021-08-12 15:42:43 +02:00
|
|
|
|
2021-10-10 01:13:37 +02:00
|
|
|
if (!dns6_set &&
|
conf, udp: Drop mostly duplicated dns_send arrays, rename related fields
Given that we use just the first valid DNS resolver address
configured, or read from resolv.conf(5) on the host, to forward DNS
queries to, in case --dns-forward is used, we don't need to duplicate
dns[] to dns_send[]:
- rename dns_send[] back to dns[]: those are the resolvers we
advertise to the guest/container
- for forwarding purposes, instead of dns[], use a single field (for
each protocol version): dns_host
- and rename dns_fwd to dns_match, so that it's clear this is the
address we are matching DNS queries against, to decide if they need
to be forwarded
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2022-11-10 20:30:03 +01:00
|
|
|
dns6 - &c->ip6.dns[0] < ARRAY_SIZE(c->ip6.dns) - 1
|
conf: Don't warn if nameservers were found, but won't be advertised
Starting from commit 3a2afde87dd1 ("conf, udp: Drop mostly duplicated
dns_send arrays, rename related fields"), we won't add to c->ip4.dns
and c->ip6.dns nameservers that can't be used by the guest or
container, and we won't advertise them.
However, the fact that we don't advertise any nameserver doesn't mean
that we didn't find any, and we should warn only if we couldn't find
any.
This is particularly relevant in case both --dns-forward and
--no-map-gw are passed, and a single loopback address is listed in
/etc/resolv.conf: we'll forward queries directed to the address
specified by --dns-forward to the loopback address we found, we
won't advertise that address, so we shouldn't warn: this is a
perfectly legitimate usage.
Reported-by: Paul Holzinger <pholzing@redhat.com>
Link: https://github.com/containers/podman/issues/19213
Fixes: 3a2afde87dd1 ("conf, udp: Drop mostly duplicated dns_send arrays, rename related fields")
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-03-08 00:12:19 +01:00
|
|
|
&& inet_pton(AF_INET6, p + 1, &dns6_tmp)) {
|
2023-02-23 14:32:30 +01:00
|
|
|
add_dns6(c, &dns6_tmp, &dns6);
|
conf: Don't warn if nameservers were found, but won't be advertised
Starting from commit 3a2afde87dd1 ("conf, udp: Drop mostly duplicated
dns_send arrays, rename related fields"), we won't add to c->ip4.dns
and c->ip6.dns nameservers that can't be used by the guest or
container, and we won't advertise them.
However, the fact that we don't advertise any nameserver doesn't mean
that we didn't find any, and we should warn only if we couldn't find
any.
This is particularly relevant in case both --dns-forward and
--no-map-gw are passed, and a single loopback address is listed in
/etc/resolv.conf: we'll forward queries directed to the address
specified by --dns-forward to the loopback address we found, we
won't advertise that address, so we shouldn't warn: this is a
perfectly legitimate usage.
Reported-by: Paul Holzinger <pholzing@redhat.com>
Link: https://github.com/containers/podman/issues/19213
Fixes: 3a2afde87dd1 ("conf, udp: Drop mostly duplicated dns_send arrays, rename related fields")
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-03-08 00:12:19 +01:00
|
|
|
added++;
|
|
|
|
}
|
2022-06-24 04:17:30 +02:00
|
|
|
} else if (!dnss_set && strstr(line, "search ") == line &&
|
2021-08-12 15:42:43 +02:00
|
|
|
s == c->dns_search) {
|
2022-06-24 04:17:30 +02:00
|
|
|
end = strpbrk(line, "\n");
|
2021-08-12 15:42:43 +02:00
|
|
|
if (end)
|
|
|
|
*end = 0;
|
|
|
|
|
2022-09-28 06:33:26 +02:00
|
|
|
/* cppcheck-suppress strtokCalled */
|
2022-06-24 04:17:30 +02:00
|
|
|
if (!strtok(line, " \t"))
|
2021-10-19 19:18:04 +02:00
|
|
|
continue;
|
|
|
|
|
2021-09-26 23:22:31 +02:00
|
|
|
while (s - c->dns_search < ARRAY_SIZE(c->dns_search) - 1
|
2022-09-28 06:33:26 +02:00
|
|
|
/* cppcheck-suppress strtokCalled */
|
2021-09-26 23:22:31 +02:00
|
|
|
&& (p = strtok(NULL, " \t"))) {
|
2021-08-12 15:42:43 +02:00
|
|
|
strncpy(s->n, p, sizeof(c->dns_search[0]));
|
|
|
|
s++;
|
2021-09-26 23:22:31 +02:00
|
|
|
*s->n = 0;
|
2021-08-12 15:42:43 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-06-24 04:17:30 +02:00
|
|
|
if (line_len < 0)
|
|
|
|
warn("Error reading /etc/resolv.conf: %s", strerror(errno));
|
2021-10-14 01:21:29 +02:00
|
|
|
close(fd);
|
2021-08-12 15:42:43 +02:00
|
|
|
|
|
|
|
out:
|
2024-03-12 19:13:46 +01:00
|
|
|
if (!dns_set) {
|
|
|
|
if (!added)
|
|
|
|
warn("Couldn't get any nameserver address");
|
|
|
|
|
|
|
|
if (c->no_dhcp_dns)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (c->ifi4 && !c->no_dhcp &&
|
|
|
|
IN4_IS_ADDR_UNSPECIFIED(&c->ip4.dns[0]))
|
|
|
|
warn("No IPv4 nameserver available for DHCP");
|
|
|
|
|
|
|
|
if (c->ifi6 && ((!c->no_ndp && !c->no_ra) || !c->no_dhcpv6) &&
|
|
|
|
IN6_IS_ADDR_UNSPECIFIED(&c->ip6.dns[0]))
|
|
|
|
warn("No IPv6 nameserver available for NDP/DHCPv6");
|
|
|
|
}
|
2021-08-12 15:42:43 +02:00
|
|
|
}
|
|
|
|
|
More deterministic detection of whether argument is a PID, PATH or NAME
pasta takes as its only non-option argument either a PID to attach to the
namespaces of, a PATH to a network namespace or a NAME of a network
namespace (relative to /run/netns). Currently to determine which it is
we try all 3 in that order, and if anything goes wrong we move onto the
next.
This has the potential to cause very confusing failure modes. e.g. if the
argument is intended to be a network namespace name, but a (non-namespace)
file of the same name exists in the current directory.
Make behaviour more predictable by choosing how to treat the argument based
only on the argument's contents, not anything else on the system:
- If it's a decimal integer treat it as a PID
- Otherwise, if it has no '/' characters, treat it as a netns name
(ip-netns doesn't allow '/' in netns names)
- Otherwise, treat it as a netns path
If you want to open a persistent netns in the current directory, you can
use './netns'.
This also allows us to split the parsing of the PID|PATH|NAME option from
the actual opening of the namespaces. In turn that allows us to put the
opening of existing namespaces next to the opening of new namespaces in
pasta_start_ns. That makes the logical flow easier to follow and will
enable later cleanups.
Caveats:
- The separation of functions mean we will always generate the basename
and dirname for the netns_quit system, even when using PID namespaces.
This is pointless, since the netns_quit system doesn't work for non
persistent namespaces, but is harmless.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-08-26 06:58:37 +02:00
|
|
|
/**
|
2022-09-12 14:24:04 +02:00
|
|
|
* conf_netns_opt() - Parse --netns option
|
2022-08-26 06:58:38 +02:00
|
|
|
* @netns: buffer of size PATH_MAX, updated with netns path
|
|
|
|
* @arg: --netns argument
|
|
|
|
*/
|
2023-02-15 09:24:35 +01:00
|
|
|
static void conf_netns_opt(char *netns, const char *arg)
|
2022-08-26 06:58:38 +02:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (!strchr(arg, '/')) {
|
|
|
|
/* looks like a netns name */
|
|
|
|
ret = snprintf(netns, PATH_MAX, "%s/%s", NETNS_RUN_DIR, arg);
|
|
|
|
} else {
|
|
|
|
/* otherwise assume it's a netns path */
|
|
|
|
ret = snprintf(netns, PATH_MAX, "%s", arg);
|
|
|
|
}
|
|
|
|
|
2023-02-15 09:24:35 +01:00
|
|
|
if (ret <= 0 || ret > PATH_MAX)
|
2023-10-13 06:50:29 +02:00
|
|
|
die("Network namespace name/path %s too long", arg);
|
2022-08-26 06:58:38 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2022-09-12 14:24:04 +02:00
|
|
|
* conf_pasta_ns() - Validate all pasta namespace options
|
|
|
|
* @netns_only: Don't use userns, may be updated
|
More deterministic detection of whether argument is a PID, PATH or NAME
pasta takes as its only non-option argument either a PID to attach to the
namespaces of, a PATH to a network namespace or a NAME of a network
namespace (relative to /run/netns). Currently to determine which it is
we try all 3 in that order, and if anything goes wrong we move onto the
next.
This has the potential to cause very confusing failure modes. e.g. if the
argument is intended to be a network namespace name, but a (non-namespace)
file of the same name exists in the current directory.
Make behaviour more predictable by choosing how to treat the argument based
only on the argument's contents, not anything else on the system:
- If it's a decimal integer treat it as a PID
- Otherwise, if it has no '/' characters, treat it as a netns name
(ip-netns doesn't allow '/' in netns names)
- Otherwise, treat it as a netns path
If you want to open a persistent netns in the current directory, you can
use './netns'.
This also allows us to split the parsing of the PID|PATH|NAME option from
the actual opening of the namespaces. In turn that allows us to put the
opening of existing namespaces next to the opening of new namespaces in
pasta_start_ns. That makes the logical flow easier to follow and will
enable later cleanups.
Caveats:
- The separation of functions mean we will always generate the basename
and dirname for the netns_quit system, even when using PID namespaces.
This is pointless, since the netns_quit system doesn't work for non
persistent namespaces, but is harmless.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-08-26 06:58:37 +02:00
|
|
|
* @userns: buffer of size PATH_MAX, initially contains --userns
|
|
|
|
* argument (may be empty), updated with userns path
|
2022-08-26 06:58:38 +02:00
|
|
|
* @netns: buffer of size PATH_MAX, initial contains --netns
|
|
|
|
* argument (may be empty), updated with netns path
|
2022-09-12 14:24:04 +02:00
|
|
|
* @optind: Index of first non-option argument
|
|
|
|
* @argc: Number of arguments
|
|
|
|
* @argv: Command line arguments
|
More deterministic detection of whether argument is a PID, PATH or NAME
pasta takes as its only non-option argument either a PID to attach to the
namespaces of, a PATH to a network namespace or a NAME of a network
namespace (relative to /run/netns). Currently to determine which it is
we try all 3 in that order, and if anything goes wrong we move onto the
next.
This has the potential to cause very confusing failure modes. e.g. if the
argument is intended to be a network namespace name, but a (non-namespace)
file of the same name exists in the current directory.
Make behaviour more predictable by choosing how to treat the argument based
only on the argument's contents, not anything else on the system:
- If it's a decimal integer treat it as a PID
- Otherwise, if it has no '/' characters, treat it as a netns name
(ip-netns doesn't allow '/' in netns names)
- Otherwise, treat it as a netns path
If you want to open a persistent netns in the current directory, you can
use './netns'.
This also allows us to split the parsing of the PID|PATH|NAME option from
the actual opening of the namespaces. In turn that allows us to put the
opening of existing namespaces next to the opening of new namespaces in
pasta_start_ns. That makes the logical flow easier to follow and will
enable later cleanups.
Caveats:
- The separation of functions mean we will always generate the basename
and dirname for the netns_quit system, even when using PID namespaces.
This is pointless, since the netns_quit system doesn't work for non
persistent namespaces, but is harmless.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-08-26 06:58:37 +02:00
|
|
|
*/
|
2023-02-15 09:24:33 +01:00
|
|
|
static void conf_pasta_ns(int *netns_only, char *userns, char *netns,
|
|
|
|
int optind, int argc, char *argv[])
|
More deterministic detection of whether argument is a PID, PATH or NAME
pasta takes as its only non-option argument either a PID to attach to the
namespaces of, a PATH to a network namespace or a NAME of a network
namespace (relative to /run/netns). Currently to determine which it is
we try all 3 in that order, and if anything goes wrong we move onto the
next.
This has the potential to cause very confusing failure modes. e.g. if the
argument is intended to be a network namespace name, but a (non-namespace)
file of the same name exists in the current directory.
Make behaviour more predictable by choosing how to treat the argument based
only on the argument's contents, not anything else on the system:
- If it's a decimal integer treat it as a PID
- Otherwise, if it has no '/' characters, treat it as a netns name
(ip-netns doesn't allow '/' in netns names)
- Otherwise, treat it as a netns path
If you want to open a persistent netns in the current directory, you can
use './netns'.
This also allows us to split the parsing of the PID|PATH|NAME option from
the actual opening of the namespaces. In turn that allows us to put the
opening of existing namespaces next to the opening of new namespaces in
pasta_start_ns. That makes the logical flow easier to follow and will
enable later cleanups.
Caveats:
- The separation of functions mean we will always generate the basename
and dirname for the netns_quit system, even when using PID namespaces.
This is pointless, since the netns_quit system doesn't work for non
persistent namespaces, but is harmless.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-08-26 06:58:37 +02:00
|
|
|
{
|
2023-02-15 09:24:33 +01:00
|
|
|
if (*netns && optind != argc)
|
|
|
|
die("Both --netns and PID or command given");
|
More deterministic detection of whether argument is a PID, PATH or NAME
pasta takes as its only non-option argument either a PID to attach to the
namespaces of, a PATH to a network namespace or a NAME of a network
namespace (relative to /run/netns). Currently to determine which it is
we try all 3 in that order, and if anything goes wrong we move onto the
next.
This has the potential to cause very confusing failure modes. e.g. if the
argument is intended to be a network namespace name, but a (non-namespace)
file of the same name exists in the current directory.
Make behaviour more predictable by choosing how to treat the argument based
only on the argument's contents, not anything else on the system:
- If it's a decimal integer treat it as a PID
- Otherwise, if it has no '/' characters, treat it as a netns name
(ip-netns doesn't allow '/' in netns names)
- Otherwise, treat it as a netns path
If you want to open a persistent netns in the current directory, you can
use './netns'.
This also allows us to split the parsing of the PID|PATH|NAME option from
the actual opening of the namespaces. In turn that allows us to put the
opening of existing namespaces next to the opening of new namespaces in
pasta_start_ns. That makes the logical flow easier to follow and will
enable later cleanups.
Caveats:
- The separation of functions mean we will always generate the basename
and dirname for the netns_quit system, even when using PID namespaces.
This is pointless, since the netns_quit system doesn't work for non
persistent namespaces, but is harmless.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-08-26 06:58:37 +02:00
|
|
|
|
2022-09-12 14:24:04 +02:00
|
|
|
if (optind + 1 == argc) {
|
|
|
|
char *endptr;
|
|
|
|
long pidval;
|
|
|
|
|
|
|
|
pidval = strtol(argv[optind], &endptr, 10);
|
|
|
|
if (!*endptr) {
|
|
|
|
/* Looks like a pid */
|
2023-02-15 09:24:33 +01:00
|
|
|
if (pidval < 0 || pidval > INT_MAX)
|
|
|
|
die("Invalid PID %s", argv[optind]);
|
2022-09-12 14:24:04 +02:00
|
|
|
|
|
|
|
snprintf(netns, PATH_MAX, "/proc/%ld/ns/net", pidval);
|
|
|
|
if (!*userns)
|
|
|
|
snprintf(userns, PATH_MAX, "/proc/%ld/ns/user",
|
|
|
|
pidval);
|
More deterministic detection of whether argument is a PID, PATH or NAME
pasta takes as its only non-option argument either a PID to attach to the
namespaces of, a PATH to a network namespace or a NAME of a network
namespace (relative to /run/netns). Currently to determine which it is
we try all 3 in that order, and if anything goes wrong we move onto the
next.
This has the potential to cause very confusing failure modes. e.g. if the
argument is intended to be a network namespace name, but a (non-namespace)
file of the same name exists in the current directory.
Make behaviour more predictable by choosing how to treat the argument based
only on the argument's contents, not anything else on the system:
- If it's a decimal integer treat it as a PID
- Otherwise, if it has no '/' characters, treat it as a netns name
(ip-netns doesn't allow '/' in netns names)
- Otherwise, treat it as a netns path
If you want to open a persistent netns in the current directory, you can
use './netns'.
This also allows us to split the parsing of the PID|PATH|NAME option from
the actual opening of the namespaces. In turn that allows us to put the
opening of existing namespaces next to the opening of new namespaces in
pasta_start_ns. That makes the logical flow easier to follow and will
enable later cleanups.
Caveats:
- The separation of functions mean we will always generate the basename
and dirname for the netns_quit system, even when using PID namespaces.
This is pointless, since the netns_quit system doesn't work for non
persistent namespaces, but is harmless.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-08-26 06:58:37 +02:00
|
|
|
}
|
2022-09-12 14:24:04 +02:00
|
|
|
}
|
More deterministic detection of whether argument is a PID, PATH or NAME
pasta takes as its only non-option argument either a PID to attach to the
namespaces of, a PATH to a network namespace or a NAME of a network
namespace (relative to /run/netns). Currently to determine which it is
we try all 3 in that order, and if anything goes wrong we move onto the
next.
This has the potential to cause very confusing failure modes. e.g. if the
argument is intended to be a network namespace name, but a (non-namespace)
file of the same name exists in the current directory.
Make behaviour more predictable by choosing how to treat the argument based
only on the argument's contents, not anything else on the system:
- If it's a decimal integer treat it as a PID
- Otherwise, if it has no '/' characters, treat it as a netns name
(ip-netns doesn't allow '/' in netns names)
- Otherwise, treat it as a netns path
If you want to open a persistent netns in the current directory, you can
use './netns'.
This also allows us to split the parsing of the PID|PATH|NAME option from
the actual opening of the namespaces. In turn that allows us to put the
opening of existing namespaces next to the opening of new namespaces in
pasta_start_ns. That makes the logical flow easier to follow and will
enable later cleanups.
Caveats:
- The separation of functions mean we will always generate the basename
and dirname for the netns_quit system, even when using PID namespaces.
This is pointless, since the netns_quit system doesn't work for non
persistent namespaces, but is harmless.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-08-26 06:58:37 +02:00
|
|
|
|
2022-09-12 14:24:04 +02:00
|
|
|
/* Attaching to a netns/PID, with no userns given */
|
|
|
|
if (*netns && !*userns)
|
|
|
|
*netns_only = 1;
|
More deterministic detection of whether argument is a PID, PATH or NAME
pasta takes as its only non-option argument either a PID to attach to the
namespaces of, a PATH to a network namespace or a NAME of a network
namespace (relative to /run/netns). Currently to determine which it is
we try all 3 in that order, and if anything goes wrong we move onto the
next.
This has the potential to cause very confusing failure modes. e.g. if the
argument is intended to be a network namespace name, but a (non-namespace)
file of the same name exists in the current directory.
Make behaviour more predictable by choosing how to treat the argument based
only on the argument's contents, not anything else on the system:
- If it's a decimal integer treat it as a PID
- Otherwise, if it has no '/' characters, treat it as a netns name
(ip-netns doesn't allow '/' in netns names)
- Otherwise, treat it as a netns path
If you want to open a persistent netns in the current directory, you can
use './netns'.
This also allows us to split the parsing of the PID|PATH|NAME option from
the actual opening of the namespaces. In turn that allows us to put the
opening of existing namespaces next to the opening of new namespaces in
pasta_start_ns. That makes the logical flow easier to follow and will
enable later cleanups.
Caveats:
- The separation of functions mean we will always generate the basename
and dirname for the netns_quit system, even when using PID namespaces.
This is pointless, since the netns_quit system doesn't work for non
persistent namespaces, but is harmless.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-08-26 06:58:37 +02:00
|
|
|
}
|
|
|
|
|
2022-11-04 04:10:33 +01:00
|
|
|
/** conf_ip4_prefix() - Parse an IPv4 prefix length or netmask
|
|
|
|
* @arg: Netmask in dotted decimal or prefix length
|
|
|
|
*
|
|
|
|
* Return: Validated prefix length on success, -1 on failure
|
|
|
|
*/
|
|
|
|
static int conf_ip4_prefix(const char *arg)
|
|
|
|
{
|
|
|
|
struct in_addr mask;
|
|
|
|
unsigned long len;
|
|
|
|
|
|
|
|
if (inet_pton(AF_INET, arg, &mask)) {
|
|
|
|
in_addr_t hmask = ntohl(mask.s_addr);
|
|
|
|
len = __builtin_popcount(hmask);
|
|
|
|
if ((hmask << len) != 0)
|
|
|
|
return -1;
|
|
|
|
} else {
|
|
|
|
errno = 0;
|
|
|
|
len = strtoul(optarg, NULL, 0);
|
|
|
|
if (len > 32 || errno)
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return len;
|
|
|
|
}
|
|
|
|
|
2021-10-11 12:01:31 +02:00
|
|
|
/**
|
2022-07-22 07:31:17 +02:00
|
|
|
* conf_ip4() - Verify or detect IPv4 support, get relevant addresses
|
|
|
|
* @ifi: Host interface to attempt (0 to determine one)
|
2022-07-22 07:31:18 +02:00
|
|
|
* @ip4: IPv4 context (will be written)
|
|
|
|
* @mac: MAC address to use (written if unset)
|
2022-07-22 07:31:17 +02:00
|
|
|
*
|
|
|
|
* Return: Interface index for IPv4, or 0 on failure.
|
2021-10-11 12:01:31 +02:00
|
|
|
*/
|
2022-07-22 07:31:18 +02:00
|
|
|
static unsigned int conf_ip4(unsigned int ifi,
|
|
|
|
struct ip4_ctx *ip4, unsigned char *mac)
|
2021-10-11 12:01:31 +02:00
|
|
|
{
|
2022-07-22 07:31:17 +02:00
|
|
|
if (!ifi)
|
2023-08-03 09:19:44 +02:00
|
|
|
ifi = nl_get_ext_if(nl_sock, AF_INET);
|
2022-07-22 07:31:13 +02:00
|
|
|
|
2022-07-22 07:31:17 +02:00
|
|
|
if (!ifi) {
|
netlink: Fix selection of template interface
Since f919dc7a4b1c ("conf, netlink: Don't require a default route to
start"), if there is only one host interface with routes, we will pick that
as the template interface, even if there are no default routes for an IP
version. Unfortunately this selection had a serious flaw: in some cases
it would 'return' in the middle of an nl_foreach() loop, meaning we
wouldn't consume all the netlink responses for our query. This could cause
later netlink operations to fail as we read leftover responses from the
aborted query.
Rewrite the interface detection to avoid this problem. While we're there:
* Perform detection of both default and non-default routes in a single
pass, avoiding an ugly goto
* Give more detail on error and working but unusual paths about the
situation (no suitable interface, multiple possible candidates, etc.).
Fixes: f919dc7a4b1c ("conf, netlink: Don't require a default route to start")
Link: https://bugs.passt.top/show_bug.cgi?id=83
Link: https://github.com/containers/podman/issues/22052
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2270257
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
[sbrivio: Use info(), not warn() for somewhat expected cases where one
IP version has no default routes, or no routes at all]
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2024-03-20 06:33:39 +01:00
|
|
|
info("Couldn't pick external interface: disabling IPv4");
|
2022-07-22 07:31:17 +02:00
|
|
|
return 0;
|
2022-07-22 07:31:13 +02:00
|
|
|
}
|
2021-10-11 12:01:31 +02:00
|
|
|
|
2023-08-03 09:19:55 +02:00
|
|
|
if (IN4_IS_ADDR_UNSPECIFIED(&ip4->gw)) {
|
|
|
|
int rc = nl_route_get_def(nl_sock, ifi, AF_INET, &ip4->gw);
|
|
|
|
if (rc < 0) {
|
|
|
|
err("Couldn't discover IPv4 gateway address: %s",
|
|
|
|
strerror(-rc));
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
2021-10-11 12:01:31 +02:00
|
|
|
|
2023-08-03 09:19:55 +02:00
|
|
|
if (IN4_IS_ADDR_UNSPECIFIED(&ip4->addr)) {
|
|
|
|
int rc = nl_addr_get(nl_sock, ifi, AF_INET,
|
|
|
|
&ip4->addr, &ip4->prefix_len, NULL);
|
|
|
|
if (rc < 0) {
|
|
|
|
err("Couldn't discover IPv4 address: %s",
|
|
|
|
strerror(-rc));
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
2021-10-19 09:01:27 +02:00
|
|
|
|
2022-11-04 04:10:33 +01:00
|
|
|
if (!ip4->prefix_len) {
|
2023-05-14 15:22:00 +02:00
|
|
|
in_addr_t addr = ntohl(ip4->addr.s_addr);
|
2022-11-04 04:10:35 +01:00
|
|
|
if (IN_CLASSA(addr))
|
2022-11-04 04:10:33 +01:00
|
|
|
ip4->prefix_len = (32 - IN_CLASSA_NSHIFT);
|
2022-11-04 04:10:35 +01:00
|
|
|
else if (IN_CLASSB(addr))
|
2022-11-04 04:10:33 +01:00
|
|
|
ip4->prefix_len = (32 - IN_CLASSB_NSHIFT);
|
2022-11-04 04:10:35 +01:00
|
|
|
else if (IN_CLASSC(addr))
|
2022-11-04 04:10:33 +01:00
|
|
|
ip4->prefix_len = (32 - IN_CLASSC_NSHIFT);
|
2022-07-22 07:31:17 +02:00
|
|
|
else
|
2022-11-04 04:10:33 +01:00
|
|
|
ip4->prefix_len = 32;
|
2022-07-22 07:31:17 +02:00
|
|
|
}
|
2021-10-11 12:01:31 +02:00
|
|
|
|
2022-07-22 07:31:18 +02:00
|
|
|
memcpy(&ip4->addr_seen, &ip4->addr, sizeof(ip4->addr_seen));
|
2021-10-11 12:01:31 +02:00
|
|
|
|
2023-08-03 09:19:55 +02:00
|
|
|
if (MAC_IS_ZERO(mac)) {
|
|
|
|
int rc = nl_link_get_mac(nl_sock, ifi, mac);
|
|
|
|
if (rc < 0) {
|
|
|
|
char ifname[IFNAMSIZ];
|
2024-04-11 18:52:33 +02:00
|
|
|
err("Couldn't discover MAC address for %s: %s",
|
2023-08-03 09:19:55 +02:00
|
|
|
if_indextoname(ifi, ifname), strerror(-rc));
|
|
|
|
return 0;
|
|
|
|
}
|
2024-04-11 23:23:04 +02:00
|
|
|
|
|
|
|
if (MAC_IS_ZERO(mac))
|
|
|
|
memcpy(mac, MAC_LAA, ETH_ALEN);
|
2023-08-03 09:19:55 +02:00
|
|
|
}
|
2021-10-11 12:01:31 +02:00
|
|
|
|
2024-04-11 23:23:04 +02:00
|
|
|
if (IN4_IS_ADDR_UNSPECIFIED(&ip4->addr))
|
2022-07-22 07:31:17 +02:00
|
|
|
return 0;
|
2021-10-19 09:01:27 +02:00
|
|
|
|
2022-07-22 07:31:17 +02:00
|
|
|
return ifi;
|
|
|
|
}
|
2021-10-11 12:01:31 +02:00
|
|
|
|
2022-07-22 07:31:17 +02:00
|
|
|
/**
|
|
|
|
* conf_ip6() - Verify or detect IPv6 support, get relevant addresses
|
|
|
|
* @ifi: Host interface to attempt (0 to determine one)
|
2022-07-22 07:31:18 +02:00
|
|
|
* @ip6: IPv6 context (will be written)
|
|
|
|
* @mac: MAC address to use (written if unset)
|
2022-07-22 07:31:17 +02:00
|
|
|
*
|
|
|
|
* Return: Interface index for IPv6, or 0 on failure.
|
|
|
|
*/
|
2022-07-22 07:31:18 +02:00
|
|
|
static unsigned int conf_ip6(unsigned int ifi,
|
|
|
|
struct ip6_ctx *ip6, unsigned char *mac)
|
2022-07-22 07:31:17 +02:00
|
|
|
{
|
|
|
|
int prefix_len = 0;
|
2023-08-03 09:19:55 +02:00
|
|
|
int rc;
|
2021-10-11 12:01:31 +02:00
|
|
|
|
2022-07-22 07:31:17 +02:00
|
|
|
if (!ifi)
|
2023-08-03 09:19:44 +02:00
|
|
|
ifi = nl_get_ext_if(nl_sock, AF_INET6);
|
2022-07-22 07:31:14 +02:00
|
|
|
|
2022-07-22 07:31:17 +02:00
|
|
|
if (!ifi) {
|
netlink: Fix selection of template interface
Since f919dc7a4b1c ("conf, netlink: Don't require a default route to
start"), if there is only one host interface with routes, we will pick that
as the template interface, even if there are no default routes for an IP
version. Unfortunately this selection had a serious flaw: in some cases
it would 'return' in the middle of an nl_foreach() loop, meaning we
wouldn't consume all the netlink responses for our query. This could cause
later netlink operations to fail as we read leftover responses from the
aborted query.
Rewrite the interface detection to avoid this problem. While we're there:
* Perform detection of both default and non-default routes in a single
pass, avoiding an ugly goto
* Give more detail on error and working but unusual paths about the
situation (no suitable interface, multiple possible candidates, etc.).
Fixes: f919dc7a4b1c ("conf, netlink: Don't require a default route to start")
Link: https://bugs.passt.top/show_bug.cgi?id=83
Link: https://github.com/containers/podman/issues/22052
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2270257
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
[sbrivio: Use info(), not warn() for somewhat expected cases where one
IP version has no default routes, or no routes at all]
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2024-03-20 06:33:39 +01:00
|
|
|
info("Couldn't pick external interface: disabling IPv6");
|
2022-07-22 07:31:17 +02:00
|
|
|
return 0;
|
2021-10-11 12:01:31 +02:00
|
|
|
}
|
|
|
|
|
2023-08-03 09:19:55 +02:00
|
|
|
if (IN6_IS_ADDR_UNSPECIFIED(&ip6->gw)) {
|
|
|
|
rc = nl_route_get_def(nl_sock, ifi, AF_INET6, &ip6->gw);
|
|
|
|
if (rc < 0) {
|
|
|
|
err("Couldn't discover IPv6 gateway address: %s",
|
|
|
|
strerror(-rc));
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
2022-07-22 07:31:17 +02:00
|
|
|
|
2023-08-03 09:19:55 +02:00
|
|
|
rc = nl_addr_get(nl_sock, ifi, AF_INET6,
|
|
|
|
IN6_IS_ADDR_UNSPECIFIED(&ip6->addr) ? &ip6->addr : NULL,
|
|
|
|
&prefix_len, &ip6->addr_ll);
|
|
|
|
if (rc < 0) {
|
|
|
|
err("Couldn't discover IPv6 address: %s", strerror(-rc));
|
|
|
|
return 0;
|
|
|
|
}
|
2022-07-22 07:31:17 +02:00
|
|
|
|
2022-07-22 07:31:18 +02:00
|
|
|
memcpy(&ip6->addr_seen, &ip6->addr, sizeof(ip6->addr));
|
|
|
|
memcpy(&ip6->addr_ll_seen, &ip6->addr_ll, sizeof(ip6->addr_ll));
|
2022-07-22 07:31:17 +02:00
|
|
|
|
2023-08-03 09:19:55 +02:00
|
|
|
if (MAC_IS_ZERO(mac)) {
|
|
|
|
rc = nl_link_get_mac(nl_sock, ifi, mac);
|
|
|
|
if (rc < 0) {
|
|
|
|
char ifname[IFNAMSIZ];
|
2024-04-11 18:52:33 +02:00
|
|
|
err("Couldn't discover MAC address for %s: %s",
|
2023-08-03 09:19:55 +02:00
|
|
|
if_indextoname(ifi, ifname), strerror(-rc));
|
|
|
|
return 0;
|
|
|
|
}
|
2024-04-11 23:23:04 +02:00
|
|
|
|
|
|
|
if (MAC_IS_ZERO(mac))
|
|
|
|
memcpy(mac, MAC_LAA, ETH_ALEN);
|
2023-08-03 09:19:55 +02:00
|
|
|
}
|
2021-10-11 12:01:31 +02:00
|
|
|
|
2023-06-02 07:02:02 +02:00
|
|
|
if (IN6_IS_ADDR_UNSPECIFIED(&ip6->addr) ||
|
2024-04-11 23:23:04 +02:00
|
|
|
IN6_IS_ADDR_UNSPECIFIED(&ip6->addr_ll))
|
2022-07-22 07:31:17 +02:00
|
|
|
return 0;
|
2021-10-11 12:01:31 +02:00
|
|
|
|
2022-07-22 07:31:17 +02:00
|
|
|
return ifi;
|
2021-10-11 12:01:31 +02:00
|
|
|
}
|
|
|
|
|
2021-08-12 15:42:43 +02:00
|
|
|
/**
|
2024-06-05 02:42:40 +02:00
|
|
|
* usage() - Print usage, exit with given status code
|
2021-08-12 15:42:43 +02:00
|
|
|
* @name: Executable name
|
2024-06-05 02:42:41 +02:00
|
|
|
* @f: Stream to print usage info to
|
2023-06-04 07:14:49 +02:00
|
|
|
* @status: Status code for exit()
|
2021-08-12 15:42:43 +02:00
|
|
|
*/
|
2024-06-05 02:42:41 +02:00
|
|
|
static void usage(const char *name, FILE *f, int status)
|
2021-08-12 15:42:43 +02:00
|
|
|
{
|
2022-02-17 01:41:28 +01:00
|
|
|
if (strstr(name, "pasta")) {
|
2024-06-05 02:42:41 +02:00
|
|
|
fprintf(f, "Usage: %s [OPTION]... [COMMAND] [ARGS]...\n", name);
|
|
|
|
fprintf(f, " %s [OPTION]... PID\n", name);
|
|
|
|
fprintf(f, " %s [OPTION]... --netns [PATH|NAME]\n", name);
|
|
|
|
fprintf(f,
|
|
|
|
"\n"
|
|
|
|
"Without PID or --netns, run the given command or a\n"
|
|
|
|
"default shell in a new network and user namespace, and\n"
|
|
|
|
"connect it via pasta.\n");
|
2021-08-12 15:42:43 +02:00
|
|
|
} else {
|
2024-06-05 02:42:41 +02:00
|
|
|
fprintf(f, "Usage: %s [OPTION]...\n", name);
|
2021-08-12 15:42:43 +02:00
|
|
|
}
|
2024-06-05 02:42:41 +02:00
|
|
|
|
|
|
|
fprintf(f,
|
|
|
|
"\n"
|
|
|
|
" -d, --debug Be verbose\n"
|
|
|
|
" --trace Be extra verbose, implies --debug\n"
|
|
|
|
" -q, --quiet Don't print informational messages\n"
|
|
|
|
" -f, --foreground Don't run in background\n"
|
conf, passt: Make --stderr do nothing, and deprecate it
The original behaviour of printing messages to standard error by
default when running from a non-interactive terminal was introduced
because the first KubeVirt integration draft used to start passt in
foreground and get messages via standard error.
For development purposes, the system logger was more convenient at
that point, and passt was running from interactive terminals only if
not started by the KubeVirt integration.
This behaviour was introduced by 84a62b79a2bc ("passt: Also log to
stderr, don't fork to background if not interactive").
Later, I added command-line options in 1e49d194d017 ("passt, pasta:
Introduce command-line options and port re-mapping") and accidentally
reversed this condition, which wasn't a problem as --stderr could
force printing to standard error anyway (and it was used by KubeVirt).
Nowadays, the KubeVirt integration uses a log file (requested via
libvirt configuration), and the same applies for Podman if one
actually needs to look at runtime logs. There are no use cases left,
as far as I know, where passt runs in foreground in non-interactive
terminals.
Seize the chance to reintroduce some sanity here. If we fork to
background, standard error is closed, so --stderr is useless in that
case.
If we run in foreground, there's no harm in printing messages to
standard error, and that accidentally became the default behaviour
anyway, so --stderr is not needed in that case.
It would be needed for non-interactive terminals, but there are no
use cases, and if there were, let's log to standard error anyway:
the user can always redirect standard error to /dev/null if needed.
Before we're up and running, we need to print to standard error anyway
if something happens, otherwise we can't report failure to start in
any kind of usage, stand-alone or in integrations.
So, make --stderr do nothing, and deprecate it.
While at it, drop a left-over comment about --foreground being the
default only for interactive terminals, because it's not the case
anymore.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2024-06-19 20:10:10 +02:00
|
|
|
" default: run in background\n"
|
2024-06-05 02:42:41 +02:00
|
|
|
" -l, --log-file PATH Log (only) to given file\n"
|
|
|
|
" --log-size BYTES Maximum size of log file\n"
|
|
|
|
" default: 1 MiB\n"
|
|
|
|
" --runas UID|UID:GID Run as given UID, GID, which can be\n"
|
|
|
|
" numeric, or login and group names\n"
|
|
|
|
" default: drop to user \"nobody\"\n"
|
|
|
|
" -h, --help Display this help message and exit\n"
|
|
|
|
" --version Show version and exit\n");
|
2021-08-12 15:42:43 +02:00
|
|
|
|
2022-02-17 01:41:28 +01:00
|
|
|
if (strstr(name, "pasta")) {
|
2024-06-05 02:42:41 +02:00
|
|
|
fprintf(f,
|
|
|
|
" -I, --ns-ifname NAME namespace interface name\n"
|
|
|
|
" default: same interface name as external one\n");
|
2021-08-12 15:42:43 +02:00
|
|
|
} else {
|
2024-06-05 02:42:41 +02:00
|
|
|
fprintf(f,
|
|
|
|
" -s, --socket PATH UNIX domain socket path\n"
|
|
|
|
" default: probe free path starting from "
|
|
|
|
UNIX_SOCK_PATH "\n", 1);
|
2021-08-12 15:42:43 +02:00
|
|
|
}
|
|
|
|
|
2024-06-05 02:42:41 +02:00
|
|
|
fprintf(f,
|
|
|
|
" -F, --fd FD Use FD as pre-opened connected socket\n"
|
|
|
|
" -p, --pcap FILE Log tap-facing traffic to pcap file\n"
|
|
|
|
" -P, --pid FILE Write own PID to the given file\n"
|
|
|
|
" -m, --mtu MTU Assign MTU via DHCP/NDP\n"
|
|
|
|
" a zero value disables assignment\n"
|
|
|
|
" default: 65520: maximum 802.3 MTU minus 802.3 header\n"
|
|
|
|
" length, rounded to 32 bits (IPv4 words)\n"
|
|
|
|
" -a, --address ADDR Assign IPv4 or IPv6 address ADDR\n"
|
|
|
|
" can be specified zero to two times (for IPv4 and IPv6)\n"
|
|
|
|
" default: use addresses from interface with default route\n"
|
|
|
|
" -n, --netmask MASK Assign IPv4 MASK, dot-decimal or bits\n"
|
|
|
|
" default: netmask from matching address on the host\n"
|
|
|
|
" -M, --mac-addr ADDR Use source MAC address ADDR\n"
|
|
|
|
" default: MAC address from interface with default route\n"
|
|
|
|
" -g, --gateway ADDR Pass IPv4 or IPv6 address as gateway\n"
|
|
|
|
" default: gateway from interface with default route\n"
|
|
|
|
" -i, --interface NAME Interface for addresses and routes\n"
|
|
|
|
" default: from --outbound-if4 and --outbound-if6, if any\n"
|
|
|
|
" otherwise interface with first default route\n"
|
|
|
|
" -o, --outbound ADDR Bind to address as outbound source\n"
|
|
|
|
" can be specified zero to two times (for IPv4 and IPv6)\n"
|
|
|
|
" default: use source address from routing tables\n"
|
|
|
|
" --outbound-if4 NAME Bind to outbound interface for IPv4\n"
|
|
|
|
" default: use interface from default route\n"
|
|
|
|
" --outbound-if6 NAME Bind to outbound interface for IPv6\n"
|
|
|
|
" default: use interface from default route\n"
|
|
|
|
" -D, --dns ADDR Use IPv4 or IPv6 address as DNS\n"
|
|
|
|
" can be specified multiple times\n"
|
|
|
|
" a single, empty option disables DNS information\n");
|
2022-02-17 01:41:28 +01:00
|
|
|
if (strstr(name, "pasta"))
|
2024-06-05 02:42:41 +02:00
|
|
|
fprintf(f, " default: don't use any addresses\n");
|
2021-08-12 15:42:43 +02:00
|
|
|
else
|
2024-06-05 02:42:41 +02:00
|
|
|
fprintf(f, " default: use addresses from /etc/resolv.conf\n");
|
|
|
|
fprintf(f,
|
|
|
|
" -S, --search LIST Space-separated list, search domains\n"
|
|
|
|
" a single, empty option disables the DNS search list\n");
|
2022-02-17 01:41:28 +01:00
|
|
|
if (strstr(name, "pasta"))
|
2024-06-05 02:42:41 +02:00
|
|
|
fprintf(f, " default: don't use any search list\n");
|
2021-08-12 15:42:43 +02:00
|
|
|
else
|
2024-06-05 02:42:41 +02:00
|
|
|
fprintf(f, " default: use search list from /etc/resolv.conf\n");
|
2021-08-12 15:42:43 +02:00
|
|
|
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
if (strstr(name, "pasta"))
|
2024-06-05 02:42:41 +02:00
|
|
|
fprintf(f, " --dhcp-dns \tPass DNS list via DHCP/DHCPv6/NDP\n");
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
else
|
2024-06-05 02:42:41 +02:00
|
|
|
fprintf(f, " --no-dhcp-dns No DNS list in DHCP/DHCPv6/NDP\n");
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
|
|
|
|
if (strstr(name, "pasta"))
|
2024-06-05 02:42:41 +02:00
|
|
|
fprintf(f, " --dhcp-search Pass list via DHCP/DHCPv6/NDP\n");
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
else
|
2024-06-05 02:42:41 +02:00
|
|
|
fprintf(f, " --no-dhcp-search No list in DHCP/DHCPv6/NDP\n");
|
|
|
|
|
|
|
|
fprintf(f,
|
|
|
|
" --dns-forward ADDR Forward DNS queries sent to ADDR\n"
|
|
|
|
" can be specified zero to two times (for IPv4 and IPv6)\n"
|
|
|
|
" default: don't forward DNS queries\n"
|
|
|
|
" --no-tcp Disable TCP protocol handler\n"
|
|
|
|
" --no-udp Disable UDP protocol handler\n"
|
|
|
|
" --no-icmp Disable ICMP/ICMPv6 protocol handler\n"
|
|
|
|
" --no-dhcp Disable DHCP server\n"
|
|
|
|
" --no-ndp Disable NDP responses\n"
|
|
|
|
" --no-dhcpv6 Disable DHCPv6 server\n"
|
|
|
|
" --no-ra Disable router advertisements\n"
|
|
|
|
" --no-map-gw Don't map gateway address to host\n"
|
|
|
|
" -4, --ipv4-only Enable IPv4 operation only\n"
|
|
|
|
" -6, --ipv6-only Enable IPv6 operation only\n");
|
2021-08-12 15:42:43 +02:00
|
|
|
|
2022-02-17 01:41:28 +01:00
|
|
|
if (strstr(name, "pasta"))
|
2021-09-29 16:11:06 +02:00
|
|
|
goto pasta_opts;
|
2021-08-12 15:42:43 +02:00
|
|
|
|
2024-06-05 02:42:41 +02:00
|
|
|
fprintf(f,
|
|
|
|
" -1, --one-off Quit after handling one single client\n"
|
|
|
|
" -t, --tcp-ports SPEC TCP port forwarding to guest\n"
|
|
|
|
" can be specified multiple times\n"
|
|
|
|
" SPEC can be:\n"
|
|
|
|
" 'none': don't forward any ports\n"
|
|
|
|
" 'all': forward all unbound, non-ephemeral ports\n"
|
|
|
|
" a comma-separated list, optionally ranged with '-'\n"
|
|
|
|
" and optional target ports after ':', with optional\n"
|
|
|
|
" address specification suffixed by '/' and optional\n"
|
|
|
|
" interface prefixed by '%%'. Ranges can be reduced by\n"
|
|
|
|
" excluding ports or ranges prefixed by '~'\n"
|
|
|
|
" Examples:\n"
|
|
|
|
" -t 22 Forward local port 22 to 22 on guest\n"
|
|
|
|
" -t 22:23 Forward local port 22 to 23 on guest\n"
|
|
|
|
" -t 22,25 Forward ports 22, 25 to ports 22, 25\n"
|
|
|
|
" -t 22-80 Forward ports 22 to 80\n"
|
|
|
|
" -t 22-80:32-90 Forward ports 22 to 80 to\n"
|
|
|
|
" corresponding port numbers plus 10\n"
|
|
|
|
" -t 192.0.2.1/5 Bind port 5 of 192.0.2.1 to guest\n"
|
|
|
|
" -t 5-25,~10-20 Forward ports 5 to 9, and 21 to 25\n"
|
|
|
|
" -t ~25 Forward all ports except for 25\n"
|
|
|
|
" default: none\n"
|
|
|
|
" -u, --udp-ports SPEC UDP port forwarding to guest\n"
|
|
|
|
" SPEC is as described for TCP above\n"
|
|
|
|
" default: none\n");
|
2021-08-12 15:42:43 +02:00
|
|
|
|
2023-06-04 07:14:49 +02:00
|
|
|
exit(status);
|
2021-08-12 15:42:43 +02:00
|
|
|
|
2021-09-29 16:11:06 +02:00
|
|
|
pasta_opts:
|
2022-10-07 04:53:40 +02:00
|
|
|
|
2024-06-05 02:42:41 +02:00
|
|
|
fprintf(f,
|
|
|
|
" -t, --tcp-ports SPEC TCP port forwarding to namespace\n"
|
|
|
|
" can be specified multiple times\n"
|
|
|
|
" SPEC can be:\n"
|
|
|
|
" 'none': don't forward any ports\n"
|
|
|
|
" 'auto': forward all ports currently bound in namespace\n"
|
|
|
|
" a comma-separated list, optionally ranged with '-'\n"
|
|
|
|
" and optional target ports after ':', with optional\n"
|
|
|
|
" address specification suffixed by '/' and optional\n"
|
|
|
|
" interface prefixed by '%%'. Examples:\n"
|
|
|
|
" -t 22 Forward local port 22 to port 22 in netns\n"
|
|
|
|
" -t 22:23 Forward local port 22 to port 23\n"
|
|
|
|
" -t 22,25 Forward ports 22, 25 to ports 22, 25\n"
|
|
|
|
" -t 22-80 Forward ports 22 to 80\n"
|
|
|
|
" -t 22-80:32-90 Forward ports 22 to 80 to\n"
|
|
|
|
" corresponding port numbers plus 10\n"
|
|
|
|
" -t 192.0.2.1/5 Bind port 5 of 192.0.2.1 to namespace\n"
|
|
|
|
" -t 5-25,~10-20 Forward ports 5 to 9, and 21 to 25\n"
|
|
|
|
" -t ~25 Forward all bound ports except for 25\n"
|
|
|
|
" default: auto\n"
|
|
|
|
" IPv6 bound ports are also forwarded for IPv4\n"
|
|
|
|
" -u, --udp-ports SPEC UDP port forwarding to namespace\n"
|
|
|
|
" SPEC is as described for TCP above\n"
|
|
|
|
" default: auto\n"
|
|
|
|
" IPv6 bound ports are also forwarded for IPv4\n"
|
|
|
|
" unless specified, with '-t auto', UDP ports with numbers\n"
|
|
|
|
" corresponding to forwarded TCP port numbers are\n"
|
|
|
|
" forwarded too\n"
|
|
|
|
" -T, --tcp-ns SPEC TCP port forwarding to init namespace\n"
|
|
|
|
" SPEC is as described above\n"
|
|
|
|
" default: auto\n"
|
|
|
|
" -U, --udp-ns SPEC UDP port forwarding to init namespace\n"
|
|
|
|
" SPEC is as described above\n"
|
|
|
|
" default: auto\n"
|
|
|
|
" --userns NSPATH Target user namespace to join\n"
|
|
|
|
" --netns PATH|NAME Target network namespace to join\n"
|
|
|
|
" --netns-only Don't join existing user namespace\n"
|
|
|
|
" implied if PATH or NAME are given without --userns\n"
|
|
|
|
" --no-netns-quit Don't quit if filesystem-bound target\n"
|
|
|
|
" network namespace is deleted\n"
|
|
|
|
" --config-net Configure tap interface in namespace\n"
|
|
|
|
" --no-copy-routes DEPRECATED:\n"
|
|
|
|
" Don't copy all routes to namespace\n"
|
|
|
|
" --no-copy-addrs DEPRECATED:\n"
|
|
|
|
" Don't copy all addresses to namespace\n"
|
|
|
|
" --ns-mac-addr ADDR Set MAC address on tap interface\n");
|
2021-08-12 15:42:43 +02:00
|
|
|
|
2023-06-04 07:14:49 +02:00
|
|
|
exit(status);
|
|
|
|
}
|
|
|
|
|
2022-03-26 07:23:21 +01:00
|
|
|
/**
|
|
|
|
* conf_print() - Print fundamental configuration parameters
|
|
|
|
* @c: Execution context
|
|
|
|
*/
|
|
|
|
static void conf_print(const struct ctx *c)
|
2021-08-12 15:42:43 +02:00
|
|
|
{
|
conf, icmp, tcp, udp: Add options to bind to outbound address and interface
I didn't notice earlier: libslirp (and slirp4netns) supports binding
outbound sockets to specific IPv4 and IPv6 addresses, to force the
source addresse selection. If we want to claim feature parity, we
should implement that as well.
Further, Podman supports specifying outbound interfaces as well, but
this is simply done by resolving the primary address for an interface
when the network back-end is started. However, since kernel version
5.7, commit c427bfec18f2 ("net: core: enable SO_BINDTODEVICE for
non-root users"), we can actually bind to a specific interface name,
which doesn't need to be validated in advance.
Implement -o / --outbound ADDR to bind to IPv4 and IPv6 addresses,
and --outbound-if4 and --outbound-if6 to bind IPv4 and IPv6 sockets
to given interfaces.
Given that it probably makes little sense to select addresses and
routes from interfaces different than the ones given for outbound
sockets, also assign those as "template" interfaces, by default,
unless explicitly overridden by '-i'.
For ICMP and UDP, we call sock_l4() to open outbound sockets, as we
already needed to bind to given ports or echo identifiers, and we
can bind() a socket only once: there, pass address (if any) and
interface (if any) for the existing bind() and setsockopt() calls.
For TCP, in general, we wouldn't otherwise bind sockets. Add a
specific helper to do that.
For UDP outbound sockets, we need to know if the final destination
of the socket is a loopback address, before we decide whether it
makes sense to bind the socket at all: move the block mangling the
address destination before the creation of the socket in the IPv4
path. This was already the case for the IPv6 path.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2023-03-08 03:29:51 +01:00
|
|
|
char buf4[INET_ADDRSTRLEN], buf6[INET6_ADDRSTRLEN], ifn[IFNAMSIZ];
|
2021-08-12 15:42:43 +02:00
|
|
|
int i;
|
|
|
|
|
2023-03-07 19:23:18 +01:00
|
|
|
info("Template interface: %s%s%s%s%s",
|
|
|
|
c->ifi4 ? if_indextoname(c->ifi4, ifn) : "",
|
|
|
|
c->ifi4 ? " (IPv4)" : "",
|
|
|
|
(c->ifi4 && c->ifi6) ? ", " : "",
|
|
|
|
c->ifi6 ? if_indextoname(c->ifi6, ifn) : "",
|
|
|
|
c->ifi6 ? " (IPv6)" : "");
|
|
|
|
|
conf, icmp, tcp, udp: Add options to bind to outbound address and interface
I didn't notice earlier: libslirp (and slirp4netns) supports binding
outbound sockets to specific IPv4 and IPv6 addresses, to force the
source addresse selection. If we want to claim feature parity, we
should implement that as well.
Further, Podman supports specifying outbound interfaces as well, but
this is simply done by resolving the primary address for an interface
when the network back-end is started. However, since kernel version
5.7, commit c427bfec18f2 ("net: core: enable SO_BINDTODEVICE for
non-root users"), we can actually bind to a specific interface name,
which doesn't need to be validated in advance.
Implement -o / --outbound ADDR to bind to IPv4 and IPv6 addresses,
and --outbound-if4 and --outbound-if6 to bind IPv4 and IPv6 sockets
to given interfaces.
Given that it probably makes little sense to select addresses and
routes from interfaces different than the ones given for outbound
sockets, also assign those as "template" interfaces, by default,
unless explicitly overridden by '-i'.
For ICMP and UDP, we call sock_l4() to open outbound sockets, as we
already needed to bind to given ports or echo identifiers, and we
can bind() a socket only once: there, pass address (if any) and
interface (if any) for the existing bind() and setsockopt() calls.
For TCP, in general, we wouldn't otherwise bind sockets. Add a
specific helper to do that.
For UDP outbound sockets, we need to know if the final destination
of the socket is a loopback address, before we decide whether it
makes sense to bind the socket at all: move the block mangling the
address destination before the creation of the socket in the IPv4
path. This was already the case for the IPv6 path.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2023-03-08 03:29:51 +01:00
|
|
|
if (*c->ip4.ifname_out || *c->ip6.ifname_out) {
|
|
|
|
info("Outbound interface: %s%s%s%s%s",
|
|
|
|
*c->ip4.ifname_out ? c->ip4.ifname_out : "",
|
|
|
|
*c->ip4.ifname_out ? " (IPv4)" : "",
|
|
|
|
(*c->ip4.ifname_out && *c->ip6.ifname_out) ? ", " : "",
|
|
|
|
*c->ip6.ifname_out ? c->ip6.ifname_out : "",
|
|
|
|
*c->ip6.ifname_out ? " (IPv6)" : "");
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!IN4_IS_ADDR_UNSPECIFIED(&c->ip4.addr_out) ||
|
|
|
|
!IN6_IS_ADDR_UNSPECIFIED(&c->ip6.addr_out)) {
|
|
|
|
info("Outbound address: %s%s%s",
|
|
|
|
IN4_IS_ADDR_UNSPECIFIED(&c->ip4.addr_out) ? "" :
|
|
|
|
inet_ntop(AF_INET, &c->ip4.addr_out, buf4, sizeof(buf4)),
|
|
|
|
(!IN4_IS_ADDR_UNSPECIFIED(&c->ip4.addr_out) &&
|
|
|
|
!IN6_IS_ADDR_UNSPECIFIED(&c->ip6.addr_out)) ? ", " : "",
|
|
|
|
IN6_IS_ADDR_UNSPECIFIED(&c->ip6.addr_out) ? "" :
|
|
|
|
inet_ntop(AF_INET6, &c->ip6.addr_out, buf6, sizeof(buf6)));
|
|
|
|
}
|
|
|
|
|
2022-07-22 07:31:12 +02:00
|
|
|
if (c->mode == MODE_PASTA)
|
|
|
|
info("Namespace interface: %s", c->pasta_ifn);
|
2021-08-12 15:42:43 +02:00
|
|
|
|
2022-07-22 07:31:14 +02:00
|
|
|
info("MAC:");
|
|
|
|
info(" host: %02x:%02x:%02x:%02x:%02x:%02x",
|
|
|
|
c->mac[0], c->mac[1], c->mac[2],
|
|
|
|
c->mac[3], c->mac[4], c->mac[5]);
|
2021-08-12 15:42:43 +02:00
|
|
|
|
2022-07-22 07:31:17 +02:00
|
|
|
if (c->ifi4) {
|
2021-08-12 15:42:43 +02:00
|
|
|
if (!c->no_dhcp) {
|
2022-11-09 18:35:17 +01:00
|
|
|
uint32_t mask;
|
|
|
|
|
|
|
|
mask = htonl(0xffffffff << (32 - c->ip4.prefix_len));
|
|
|
|
|
2021-08-12 15:42:43 +02:00
|
|
|
info("DHCP:");
|
|
|
|
info(" assign: %s",
|
2022-07-22 07:31:18 +02:00
|
|
|
inet_ntop(AF_INET, &c->ip4.addr, buf4, sizeof(buf4)));
|
2021-08-12 15:42:43 +02:00
|
|
|
info(" mask: %s",
|
2022-11-04 04:10:33 +01:00
|
|
|
inet_ntop(AF_INET, &mask, buf4, sizeof(buf4)));
|
2021-08-12 15:42:43 +02:00
|
|
|
info(" router: %s",
|
2022-07-22 07:31:18 +02:00
|
|
|
inet_ntop(AF_INET, &c->ip4.gw, buf4, sizeof(buf4)));
|
2021-08-12 15:42:43 +02:00
|
|
|
}
|
|
|
|
|
conf, udp: Drop mostly duplicated dns_send arrays, rename related fields
Given that we use just the first valid DNS resolver address
configured, or read from resolv.conf(5) on the host, to forward DNS
queries to, in case --dns-forward is used, we don't need to duplicate
dns[] to dns_send[]:
- rename dns_send[] back to dns[]: those are the resolvers we
advertise to the guest/container
- for forwarding purposes, instead of dns[], use a single field (for
each protocol version): dns_host
- and rename dns_fwd to dns_match, so that it's clear this is the
address we are matching DNS queries against, to decide if they need
to be forwarded
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2022-11-10 20:30:03 +01:00
|
|
|
for (i = 0; !IN4_IS_ADDR_UNSPECIFIED(&c->ip4.dns[i]); i++) {
|
2021-08-12 15:42:43 +02:00
|
|
|
if (!i)
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
info("DNS:");
|
conf, udp: Drop mostly duplicated dns_send arrays, rename related fields
Given that we use just the first valid DNS resolver address
configured, or read from resolv.conf(5) on the host, to forward DNS
queries to, in case --dns-forward is used, we don't need to duplicate
dns[] to dns_send[]:
- rename dns_send[] back to dns[]: those are the resolvers we
advertise to the guest/container
- for forwarding purposes, instead of dns[], use a single field (for
each protocol version): dns_host
- and rename dns_fwd to dns_match, so that it's clear this is the
address we are matching DNS queries against, to decide if they need
to be forwarded
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2022-11-10 20:30:03 +01:00
|
|
|
inet_ntop(AF_INET, &c->ip4.dns[i], buf4, sizeof(buf4));
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
info(" %s", buf4);
|
2021-08-12 15:42:43 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; *c->dns_search[i].n; i++) {
|
|
|
|
if (!i)
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
info("DNS search list:");
|
|
|
|
info(" %s", c->dns_search[i].n);
|
2021-08-12 15:42:43 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-07-22 07:31:17 +02:00
|
|
|
if (c->ifi6) {
|
2021-08-12 15:42:43 +02:00
|
|
|
if (!c->no_ndp && !c->no_dhcpv6)
|
|
|
|
info("NDP/DHCPv6:");
|
|
|
|
else if (!c->no_ndp)
|
|
|
|
info("DHCPv6:");
|
|
|
|
else if (!c->no_dhcpv6)
|
|
|
|
info("NDP:");
|
|
|
|
else
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
goto dns6;
|
2021-08-12 15:42:43 +02:00
|
|
|
|
|
|
|
info(" assign: %s",
|
2022-07-22 07:31:18 +02:00
|
|
|
inet_ntop(AF_INET6, &c->ip6.addr, buf6, sizeof(buf6)));
|
2021-08-12 15:42:43 +02:00
|
|
|
info(" router: %s",
|
2022-07-22 07:31:18 +02:00
|
|
|
inet_ntop(AF_INET6, &c->ip6.gw, buf6, sizeof(buf6)));
|
2021-10-10 01:09:25 +02:00
|
|
|
info(" our link-local: %s",
|
2022-07-22 07:31:18 +02:00
|
|
|
inet_ntop(AF_INET6, &c->ip6.addr_ll, buf6, sizeof(buf6)));
|
2021-08-12 15:42:43 +02:00
|
|
|
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
dns6:
|
conf, udp: Drop mostly duplicated dns_send arrays, rename related fields
Given that we use just the first valid DNS resolver address
configured, or read from resolv.conf(5) on the host, to forward DNS
queries to, in case --dns-forward is used, we don't need to duplicate
dns[] to dns_send[]:
- rename dns_send[] back to dns[]: those are the resolvers we
advertise to the guest/container
- for forwarding purposes, instead of dns[], use a single field (for
each protocol version): dns_host
- and rename dns_fwd to dns_match, so that it's clear this is the
address we are matching DNS queries against, to decide if they need
to be forwarded
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2022-11-10 20:30:03 +01:00
|
|
|
for (i = 0; !IN6_IS_ADDR_UNSPECIFIED(&c->ip6.dns[i]); i++) {
|
2021-08-12 15:42:43 +02:00
|
|
|
if (!i)
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
info("DNS:");
|
2022-07-22 07:31:18 +02:00
|
|
|
inet_ntop(AF_INET6, &c->ip6.dns[i], buf6, sizeof(buf6));
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
info(" %s", buf6);
|
2021-08-12 15:42:43 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; *c->dns_search[i].n; i++) {
|
|
|
|
if (!i)
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
info("DNS search list:");
|
|
|
|
info(" %s", c->dns_search[i].n);
|
2021-08-12 15:42:43 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-05-18 19:10:45 +02:00
|
|
|
/**
|
|
|
|
* conf_runas() - Handle --runas: look up desired UID and GID
|
|
|
|
* @opt: Passed option value
|
|
|
|
* @uid: User ID, set on return if valid
|
|
|
|
* @gid: Group ID, set on return if valid
|
|
|
|
*
|
|
|
|
* Return: 0 on success, negative error code on failure
|
|
|
|
*/
|
2022-09-28 06:33:18 +02:00
|
|
|
static int conf_runas(char *opt, unsigned int *uid, unsigned int *gid)
|
2022-05-18 19:10:45 +02:00
|
|
|
{
|
2022-09-28 06:33:18 +02:00
|
|
|
const char *uopt, *gopt = NULL;
|
|
|
|
char *sep = strchr(opt, ':');
|
|
|
|
char *endptr;
|
2022-05-18 19:10:45 +02:00
|
|
|
|
2022-09-28 06:33:18 +02:00
|
|
|
if (sep) {
|
|
|
|
*sep = '\0';
|
|
|
|
gopt = sep + 1;
|
|
|
|
}
|
|
|
|
uopt = opt;
|
2022-05-18 19:10:45 +02:00
|
|
|
|
2022-09-28 06:33:18 +02:00
|
|
|
*gid = *uid = strtol(uopt, &endptr, 0);
|
|
|
|
if (*endptr) {
|
|
|
|
#ifndef GLIBC_NO_STATIC_NSS
|
|
|
|
/* Not numeric, look up as a username */
|
2024-01-15 07:39:43 +01:00
|
|
|
const struct passwd *pw;
|
2022-09-28 06:33:18 +02:00
|
|
|
/* cppcheck-suppress getpwnamCalled */
|
|
|
|
if (!(pw = getpwnam(uopt)) || !(*uid = pw->pw_uid))
|
2022-05-18 19:10:45 +02:00
|
|
|
return -ENOENT;
|
2022-09-28 06:33:18 +02:00
|
|
|
*gid = pw->pw_gid;
|
|
|
|
#else
|
|
|
|
return -EINVAL;
|
|
|
|
#endif
|
|
|
|
}
|
2022-05-18 19:10:45 +02:00
|
|
|
|
2022-09-28 06:33:18 +02:00
|
|
|
if (!gopt)
|
2022-05-18 19:10:45 +02:00
|
|
|
return 0;
|
|
|
|
|
2022-09-28 06:33:18 +02:00
|
|
|
*gid = strtol(gopt, &endptr, 0);
|
|
|
|
if (*endptr) {
|
|
|
|
#ifndef GLIBC_NO_STATIC_NSS
|
|
|
|
/* Not numeric, look up as a group name */
|
2024-01-15 07:39:43 +01:00
|
|
|
const struct group *gr;
|
2022-09-28 06:33:18 +02:00
|
|
|
/* cppcheck-suppress getgrnamCalled */
|
|
|
|
if (!(gr = getgrnam(gopt)))
|
|
|
|
return -ENOENT;
|
|
|
|
*gid = gr->gr_gid;
|
|
|
|
#else
|
|
|
|
return -EINVAL;
|
|
|
|
#endif
|
|
|
|
}
|
2022-05-18 19:10:45 +02:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2022-09-12 14:24:01 +02:00
|
|
|
/**
|
|
|
|
* conf_ugid() - Determine UID and GID to run as
|
|
|
|
* @runas: --runas option, may be NULL
|
|
|
|
* @uid: User ID, set on success
|
|
|
|
* @gid: Group ID, set on success
|
|
|
|
*/
|
2023-02-15 09:24:34 +01:00
|
|
|
static void conf_ugid(char *runas, uid_t *uid, gid_t *gid)
|
2022-09-12 14:24:01 +02:00
|
|
|
{
|
|
|
|
/* If user has specified --runas, that takes precedence... */
|
|
|
|
if (runas) {
|
2023-02-15 09:24:34 +01:00
|
|
|
if (conf_runas(runas, uid, gid))
|
|
|
|
die("Invalid --runas option: %s", runas);
|
|
|
|
return;
|
2022-09-12 14:24:01 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* ...otherwise default to current user and group... */
|
|
|
|
*uid = geteuid();
|
|
|
|
*gid = getegid();
|
|
|
|
|
|
|
|
/* ...as long as it's not root... */
|
|
|
|
if (*uid)
|
2023-02-15 09:24:34 +01:00
|
|
|
return;
|
2022-09-12 14:24:01 +02:00
|
|
|
|
|
|
|
/* ...or at least not root in the init namespace... */
|
2023-05-21 14:47:07 +02:00
|
|
|
if (!ns_is_init())
|
2023-02-15 09:24:34 +01:00
|
|
|
return;
|
2022-09-12 14:24:01 +02:00
|
|
|
|
|
|
|
/* ...otherwise use nobody:nobody */
|
2024-05-22 20:18:19 +02:00
|
|
|
warn("Started as root, will change to nobody.");
|
2022-09-28 06:33:18 +02:00
|
|
|
{
|
2022-09-12 14:24:01 +02:00
|
|
|
#ifndef GLIBC_NO_STATIC_NSS
|
2024-01-15 07:39:43 +01:00
|
|
|
const struct passwd *pw;
|
2022-09-28 06:33:18 +02:00
|
|
|
/* cppcheck-suppress getpwnamCalled */
|
|
|
|
pw = getpwnam("nobody");
|
|
|
|
if (!pw) {
|
|
|
|
perror("getpwnam");
|
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
2022-09-12 14:24:01 +02:00
|
|
|
|
2022-09-28 06:33:18 +02:00
|
|
|
*uid = pw->pw_uid;
|
|
|
|
*gid = pw->pw_gid;
|
2022-09-12 14:24:01 +02:00
|
|
|
#else
|
2022-09-28 06:33:18 +02:00
|
|
|
/* Common value for 'nobody', not really specified */
|
|
|
|
*uid = *gid = 65534;
|
2022-09-12 14:24:01 +02:00
|
|
|
#endif
|
2022-09-28 06:33:18 +02:00
|
|
|
}
|
2022-09-12 14:24:01 +02:00
|
|
|
}
|
|
|
|
|
2024-05-22 20:18:19 +02:00
|
|
|
/**
|
|
|
|
* conf_open_files() - Open files as requested by configuration
|
|
|
|
* @c: Execution context
|
|
|
|
*/
|
|
|
|
static void conf_open_files(struct ctx *c)
|
|
|
|
{
|
2024-06-13 14:36:53 +02:00
|
|
|
if (c->mode != MODE_PASTA && c->fd_tap == -1)
|
2024-05-22 20:18:19 +02:00
|
|
|
c->fd_tap_listen = tap_sock_unix_open(c->sock_path);
|
|
|
|
|
2024-05-22 20:39:30 +02:00
|
|
|
c->pidfile_fd = pidfile_open(c->pidfile);
|
2024-05-22 20:18:19 +02:00
|
|
|
}
|
|
|
|
|
2024-06-06 12:09:47 +02:00
|
|
|
/**
|
|
|
|
* parse_mac - Parse a MAC address from a string
|
|
|
|
* @mac: Binary MAC address, initialised on success
|
|
|
|
* @str: String to parse
|
|
|
|
*
|
|
|
|
* Parses @str as an Ethernet MAC address stored in @mac on success. Exits on
|
|
|
|
* failure.
|
|
|
|
*/
|
|
|
|
static void parse_mac(unsigned char mac[ETH_ALEN], const char *str)
|
|
|
|
{
|
|
|
|
size_t i;
|
|
|
|
|
|
|
|
if (strlen(str) != (ETH_ALEN * 3 - 1))
|
|
|
|
goto fail;
|
|
|
|
|
|
|
|
for (i = 0; i < ETH_ALEN; i++) {
|
|
|
|
const char *octet = str + 3 * i;
|
|
|
|
unsigned long b;
|
|
|
|
char *end;
|
|
|
|
|
|
|
|
errno = 0;
|
|
|
|
b = strtoul(octet, &end, 16);
|
|
|
|
if (b > UCHAR_MAX || errno || end != octet + 2 ||
|
|
|
|
*end != ((i == ETH_ALEN - 1) ? '\0' : ':'))
|
|
|
|
goto fail;
|
|
|
|
mac[i] = b;
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
|
|
|
|
fail:
|
|
|
|
die("Invalid MAC address: %s", str);
|
|
|
|
}
|
|
|
|
|
2021-08-12 15:42:43 +02:00
|
|
|
/**
|
|
|
|
* conf() - Process command-line arguments and set configuration
|
|
|
|
* @c: Execution context
|
|
|
|
* @argc: Argument count
|
|
|
|
* @argv: Options, plus target PID for pasta mode
|
|
|
|
*/
|
|
|
|
void conf(struct ctx *c, int argc, char **argv)
|
|
|
|
{
|
2022-09-12 14:24:07 +02:00
|
|
|
int netns_only = 0;
|
2023-09-29 07:50:19 +02:00
|
|
|
const struct option options[] = {
|
2021-08-12 15:42:43 +02:00
|
|
|
{"debug", no_argument, NULL, 'd' },
|
2021-10-07 04:07:59 +02:00
|
|
|
{"quiet", no_argument, NULL, 'q' },
|
2021-08-12 15:42:43 +02:00
|
|
|
{"foreground", no_argument, NULL, 'f' },
|
2022-01-27 16:42:19 +01:00
|
|
|
{"stderr", no_argument, NULL, 'e' },
|
2022-10-06 14:51:04 +02:00
|
|
|
{"log-file", required_argument, NULL, 'l' },
|
2021-08-12 15:42:43 +02:00
|
|
|
{"help", no_argument, NULL, 'h' },
|
|
|
|
{"socket", required_argument, NULL, 's' },
|
2022-11-17 19:49:34 +01:00
|
|
|
{"fd", required_argument, NULL, 'F' },
|
2021-08-12 15:42:43 +02:00
|
|
|
{"ns-ifname", required_argument, NULL, 'I' },
|
2022-08-26 06:58:32 +02:00
|
|
|
{"pcap", required_argument, NULL, 'p' },
|
2021-10-14 12:17:47 +02:00
|
|
|
{"pid", required_argument, NULL, 'P' },
|
2021-08-12 15:42:43 +02:00
|
|
|
{"mtu", required_argument, NULL, 'm' },
|
|
|
|
{"address", required_argument, NULL, 'a' },
|
|
|
|
{"netmask", required_argument, NULL, 'n' },
|
|
|
|
{"mac-addr", required_argument, NULL, 'M' },
|
|
|
|
{"gateway", required_argument, NULL, 'g' },
|
|
|
|
{"interface", required_argument, NULL, 'i' },
|
conf, icmp, tcp, udp: Add options to bind to outbound address and interface
I didn't notice earlier: libslirp (and slirp4netns) supports binding
outbound sockets to specific IPv4 and IPv6 addresses, to force the
source addresse selection. If we want to claim feature parity, we
should implement that as well.
Further, Podman supports specifying outbound interfaces as well, but
this is simply done by resolving the primary address for an interface
when the network back-end is started. However, since kernel version
5.7, commit c427bfec18f2 ("net: core: enable SO_BINDTODEVICE for
non-root users"), we can actually bind to a specific interface name,
which doesn't need to be validated in advance.
Implement -o / --outbound ADDR to bind to IPv4 and IPv6 addresses,
and --outbound-if4 and --outbound-if6 to bind IPv4 and IPv6 sockets
to given interfaces.
Given that it probably makes little sense to select addresses and
routes from interfaces different than the ones given for outbound
sockets, also assign those as "template" interfaces, by default,
unless explicitly overridden by '-i'.
For ICMP and UDP, we call sock_l4() to open outbound sockets, as we
already needed to bind to given ports or echo identifiers, and we
can bind() a socket only once: there, pass address (if any) and
interface (if any) for the existing bind() and setsockopt() calls.
For TCP, in general, we wouldn't otherwise bind sockets. Add a
specific helper to do that.
For UDP outbound sockets, we need to know if the final destination
of the socket is a loopback address, before we decide whether it
makes sense to bind the socket at all: move the block mangling the
address destination before the creation of the socket in the IPv4
path. This was already the case for the IPv6 path.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2023-03-08 03:29:51 +01:00
|
|
|
{"outbound", required_argument, NULL, 'o' },
|
2022-08-26 06:58:33 +02:00
|
|
|
{"dns", required_argument, NULL, 'D' },
|
|
|
|
{"search", required_argument, NULL, 'S' },
|
2021-08-12 15:42:43 +02:00
|
|
|
{"no-tcp", no_argument, &c->no_tcp, 1 },
|
|
|
|
{"no-udp", no_argument, &c->no_udp, 1 },
|
|
|
|
{"no-icmp", no_argument, &c->no_icmp, 1 },
|
|
|
|
{"no-dhcp", no_argument, &c->no_dhcp, 1 },
|
|
|
|
{"no-dhcpv6", no_argument, &c->no_dhcpv6, 1 },
|
|
|
|
{"no-ndp", no_argument, &c->no_ndp, 1 },
|
|
|
|
{"no-ra", no_argument, &c->no_ra, 1 },
|
2021-10-14 05:26:37 +02:00
|
|
|
{"no-map-gw", no_argument, &c->no_map_gw, 1 },
|
2022-07-22 07:31:16 +02:00
|
|
|
{"ipv4-only", no_argument, NULL, '4' },
|
|
|
|
{"ipv6-only", no_argument, NULL, '6' },
|
2022-10-07 04:01:56 +02:00
|
|
|
{"one-off", no_argument, NULL, '1' },
|
2021-08-12 15:42:43 +02:00
|
|
|
{"tcp-ports", required_argument, NULL, 't' },
|
|
|
|
{"udp-ports", required_argument, NULL, 'u' },
|
|
|
|
{"tcp-ns", required_argument, NULL, 'T' },
|
|
|
|
{"udp-ns", required_argument, NULL, 'U' },
|
2021-09-29 16:11:06 +02:00
|
|
|
{"userns", required_argument, NULL, 2 },
|
2022-08-26 06:58:38 +02:00
|
|
|
{"netns", required_argument, NULL, 3 },
|
2021-10-11 12:01:31 +02:00
|
|
|
{"ns-mac-addr", required_argument, NULL, 4 },
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
{"dhcp-dns", no_argument, NULL, 5 },
|
|
|
|
{"no-dhcp-dns", no_argument, NULL, 6 },
|
|
|
|
{"dhcp-search", no_argument, NULL, 7 },
|
|
|
|
{"no-dhcp-search", no_argument, NULL, 8 },
|
|
|
|
{"dns-forward", required_argument, NULL, 9 },
|
2022-02-18 16:12:11 +01:00
|
|
|
{"no-netns-quit", no_argument, NULL, 10 },
|
2022-03-15 00:59:09 +01:00
|
|
|
{"trace", no_argument, NULL, 11 },
|
2022-05-18 19:10:45 +02:00
|
|
|
{"runas", required_argument, NULL, 12 },
|
2022-10-06 14:51:04 +02:00
|
|
|
{"log-size", required_argument, NULL, 13 },
|
2022-10-10 10:35:47 +02:00
|
|
|
{"version", no_argument, NULL, 14 },
|
conf, icmp, tcp, udp: Add options to bind to outbound address and interface
I didn't notice earlier: libslirp (and slirp4netns) supports binding
outbound sockets to specific IPv4 and IPv6 addresses, to force the
source addresse selection. If we want to claim feature parity, we
should implement that as well.
Further, Podman supports specifying outbound interfaces as well, but
this is simply done by resolving the primary address for an interface
when the network back-end is started. However, since kernel version
5.7, commit c427bfec18f2 ("net: core: enable SO_BINDTODEVICE for
non-root users"), we can actually bind to a specific interface name,
which doesn't need to be validated in advance.
Implement -o / --outbound ADDR to bind to IPv4 and IPv6 addresses,
and --outbound-if4 and --outbound-if6 to bind IPv4 and IPv6 sockets
to given interfaces.
Given that it probably makes little sense to select addresses and
routes from interfaces different than the ones given for outbound
sockets, also assign those as "template" interfaces, by default,
unless explicitly overridden by '-i'.
For ICMP and UDP, we call sock_l4() to open outbound sockets, as we
already needed to bind to given ports or echo identifiers, and we
can bind() a socket only once: there, pass address (if any) and
interface (if any) for the existing bind() and setsockopt() calls.
For TCP, in general, we wouldn't otherwise bind sockets. Add a
specific helper to do that.
For UDP outbound sockets, we need to know if the final destination
of the socket is a loopback address, before we decide whether it
makes sense to bind the socket at all: move the block mangling the
address destination before the creation of the socket in the IPv4
path. This was already the case for the IPv6 path.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2023-03-08 03:29:51 +01:00
|
|
|
{"outbound-if4", required_argument, NULL, 15 },
|
|
|
|
{"outbound-if6", required_argument, NULL, 16 },
|
2023-05-14 14:14:29 +02:00
|
|
|
{"config-net", no_argument, NULL, 17 },
|
2023-05-14 15:04:38 +02:00
|
|
|
{"no-copy-routes", no_argument, NULL, 18 },
|
2023-05-14 19:12:09 +02:00
|
|
|
{"no-copy-addrs", no_argument, NULL, 19 },
|
conf: Accept duplicate and conflicting options, the last one wins
In multiple occasions, especially when passt(1) and pasta(1) are used
in integrations such as the one with Podman, the ability to override
earlier options on the command line with later one would have been
convenient.
Recently, to debug a number of issues happening with Podman, I would
have liked to ask users to share a debug log by passing --debug as
additional option, but pasta refuses --quiet (always passed by Podman)
and --debug at the same time.
On top of this, Podman lets users specify other pasta options in its
containers.conf(5) file, as well as on the command line.
The options from the configuration files are appended together with
the ones from the command line, which makes it impossible for users to
override options from the configuration file, if duplicated options
are refused, unless Podman takes care of sorting them, which is
clearly not sustainable.
For --debug and --trace, somebody took care of this on Podman side at:
https://github.com/containers/common/pull/2052
but this doesn't fix the issue with other options, and we'll have
anyway older versions of Podman around, too.
I think there's some value in telling users about duplicated or
conflicting options, because that might reveal issues in integrations
or accidental misconfigurations, but by now I'm fairly convinced that
the downsides outweigh this.
Drop checks about duplicate options and mutually exclusive ones. In
some cases, we need to also undo a couple of initialisations caused
by earlier options, but this looks like a simplification, overall.
Notable exception: --stderr still conflicts with --log-file, because
users might have the expectation that they don't actually conflict.
But they do conflict in the existing implementation, so it's safer
to make sure that the users notice that.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 18:04:49 +02:00
|
|
|
{"netns-only", no_argument, NULL, 20 },
|
2021-08-12 15:42:43 +02:00
|
|
|
{ 0 },
|
|
|
|
};
|
More deterministic detection of whether argument is a PID, PATH or NAME
pasta takes as its only non-option argument either a PID to attach to the
namespaces of, a PATH to a network namespace or a NAME of a network
namespace (relative to /run/netns). Currently to determine which it is
we try all 3 in that order, and if anything goes wrong we move onto the
next.
This has the potential to cause very confusing failure modes. e.g. if the
argument is intended to be a network namespace name, but a (non-namespace)
file of the same name exists in the current directory.
Make behaviour more predictable by choosing how to treat the argument based
only on the argument's contents, not anything else on the system:
- If it's a decimal integer treat it as a PID
- Otherwise, if it has no '/' characters, treat it as a netns name
(ip-netns doesn't allow '/' in netns names)
- Otherwise, treat it as a netns path
If you want to open a persistent netns in the current directory, you can
use './netns'.
This also allows us to split the parsing of the PID|PATH|NAME option from
the actual opening of the namespaces. In turn that allows us to put the
opening of existing namespaces next to the opening of new namespaces in
pasta_start_ns. That makes the logical flow easier to follow and will
enable later cleanups.
Caveats:
- The separation of functions mean we will always generate the basename
and dirname for the netns_quit system, even when using PID namespaces.
This is pointless, since the netns_quit system doesn't work for non
persistent namespaces, but is harmless.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-08-26 06:58:37 +02:00
|
|
|
char userns[PATH_MAX] = { 0 }, netns[PATH_MAX] = { 0 };
|
2023-06-23 09:52:36 +02:00
|
|
|
bool copy_addrs_opt = false, copy_routes_opt = false;
|
2024-03-12 01:51:56 +01:00
|
|
|
struct in6_addr *dns6 = c->ip6.dns, dns6_tmp;
|
|
|
|
struct in_addr *dns4 = c->ip4.dns, dns4_tmp;
|
2024-02-28 12:25:20 +01:00
|
|
|
enum fwd_ports_mode fwd_default = FWD_NONE;
|
2022-07-22 07:31:16 +02:00
|
|
|
bool v4_only = false, v6_only = false;
|
2021-08-12 15:42:43 +02:00
|
|
|
struct fqdn *dnss = c->dns_search;
|
conf, icmp, tcp, udp: Add options to bind to outbound address and interface
I didn't notice earlier: libslirp (and slirp4netns) supports binding
outbound sockets to specific IPv4 and IPv6 addresses, to force the
source addresse selection. If we want to claim feature parity, we
should implement that as well.
Further, Podman supports specifying outbound interfaces as well, but
this is simply done by resolving the primary address for an interface
when the network back-end is started. However, since kernel version
5.7, commit c427bfec18f2 ("net: core: enable SO_BINDTODEVICE for
non-root users"), we can actually bind to a specific interface name,
which doesn't need to be validated in advance.
Implement -o / --outbound ADDR to bind to IPv4 and IPv6 addresses,
and --outbound-if4 and --outbound-if6 to bind IPv4 and IPv6 sockets
to given interfaces.
Given that it probably makes little sense to select addresses and
routes from interfaces different than the ones given for outbound
sockets, also assign those as "template" interfaces, by default,
unless explicitly overridden by '-i'.
For ICMP and UDP, we call sock_l4() to open outbound sockets, as we
already needed to bind to given ports or echo identifiers, and we
can bind() a socket only once: there, pass address (if any) and
interface (if any) for the existing bind() and setsockopt() calls.
For TCP, in general, we wouldn't otherwise bind sockets. Add a
specific helper to do that.
For UDP outbound sockets, we need to know if the final destination
of the socket is a loopback address, before we decide whether it
makes sense to bind the socket at all: move the block mangling the
address destination before the creation of the socket in the IPv4
path. This was already the case for the IPv6 path.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2023-03-08 03:29:51 +01:00
|
|
|
unsigned int ifi4 = 0, ifi6 = 0;
|
2024-01-15 07:39:43 +01:00
|
|
|
const char *logfile = NULL;
|
2022-10-06 12:55:03 +02:00
|
|
|
const char *optstring;
|
2022-10-06 14:51:04 +02:00
|
|
|
size_t logsize = 0;
|
2024-01-15 07:39:43 +01:00
|
|
|
char *runas = NULL;
|
2024-06-06 12:09:47 +02:00
|
|
|
int name, ret;
|
2022-09-12 14:24:01 +02:00
|
|
|
uid_t uid;
|
|
|
|
gid_t gid;
|
2021-08-12 15:42:43 +02:00
|
|
|
|
2022-10-06 12:55:03 +02:00
|
|
|
if (c->mode == MODE_PASTA) {
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
c->no_dhcp_dns = c->no_dhcp_dns_search = 1;
|
2023-11-03 03:22:55 +01:00
|
|
|
fwd_default = FWD_AUTO;
|
conf, icmp, tcp, udp: Add options to bind to outbound address and interface
I didn't notice earlier: libslirp (and slirp4netns) supports binding
outbound sockets to specific IPv4 and IPv6 addresses, to force the
source addresse selection. If we want to claim feature parity, we
should implement that as well.
Further, Podman supports specifying outbound interfaces as well, but
this is simply done by resolving the primary address for an interface
when the network back-end is started. However, since kernel version
5.7, commit c427bfec18f2 ("net: core: enable SO_BINDTODEVICE for
non-root users"), we can actually bind to a specific interface name,
which doesn't need to be validated in advance.
Implement -o / --outbound ADDR to bind to IPv4 and IPv6 addresses,
and --outbound-if4 and --outbound-if6 to bind IPv4 and IPv6 sockets
to given interfaces.
Given that it probably makes little sense to select addresses and
routes from interfaces different than the ones given for outbound
sockets, also assign those as "template" interfaces, by default,
unless explicitly overridden by '-i'.
For ICMP and UDP, we call sock_l4() to open outbound sockets, as we
already needed to bind to given ports or echo identifiers, and we
can bind() a socket only once: there, pass address (if any) and
interface (if any) for the existing bind() and setsockopt() calls.
For TCP, in general, we wouldn't otherwise bind sockets. Add a
specific helper to do that.
For UDP outbound sockets, we need to know if the final destination
of the socket is a loopback address, before we decide whether it
makes sense to bind the socket at all: move the block mangling the
address destination before the creation of the socket in the IPv4
path. This was already the case for the IPv6 path.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2023-03-08 03:29:51 +01:00
|
|
|
optstring = "dqfel:hF:I:p:P:m:a:n:M:g:i:o:D:S:46t:u:T:U:";
|
2022-10-06 12:55:03 +02:00
|
|
|
} else {
|
conf, icmp, tcp, udp: Add options to bind to outbound address and interface
I didn't notice earlier: libslirp (and slirp4netns) supports binding
outbound sockets to specific IPv4 and IPv6 addresses, to force the
source addresse selection. If we want to claim feature parity, we
should implement that as well.
Further, Podman supports specifying outbound interfaces as well, but
this is simply done by resolving the primary address for an interface
when the network back-end is started. However, since kernel version
5.7, commit c427bfec18f2 ("net: core: enable SO_BINDTODEVICE for
non-root users"), we can actually bind to a specific interface name,
which doesn't need to be validated in advance.
Implement -o / --outbound ADDR to bind to IPv4 and IPv6 addresses,
and --outbound-if4 and --outbound-if6 to bind IPv4 and IPv6 sockets
to given interfaces.
Given that it probably makes little sense to select addresses and
routes from interfaces different than the ones given for outbound
sockets, also assign those as "template" interfaces, by default,
unless explicitly overridden by '-i'.
For ICMP and UDP, we call sock_l4() to open outbound sockets, as we
already needed to bind to given ports or echo identifiers, and we
can bind() a socket only once: there, pass address (if any) and
interface (if any) for the existing bind() and setsockopt() calls.
For TCP, in general, we wouldn't otherwise bind sockets. Add a
specific helper to do that.
For UDP outbound sockets, we need to know if the final destination
of the socket is a loopback address, before we decide whether it
makes sense to bind the socket at all: move the block mangling the
address destination before the creation of the socket in the IPv4
path. This was already the case for the IPv6 path.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2023-03-08 03:29:51 +01:00
|
|
|
optstring = "dqfel:hs:F:p:P:m:a:n:M:g:i:o:D:S:461t:u:";
|
2022-10-06 12:55:03 +02:00
|
|
|
}
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
|
2024-05-13 16:57:57 +02:00
|
|
|
c->tcp.fwd_in.mode = c->tcp.fwd_out.mode = FWD_UNSET;
|
|
|
|
c->udp.fwd_in.f.mode = c->udp.fwd_out.f.mode = FWD_UNSET;
|
2022-09-24 11:08:16 +02:00
|
|
|
|
2021-08-12 15:42:43 +02:00
|
|
|
do {
|
|
|
|
name = getopt_long(argc, argv, optstring, options, NULL);
|
|
|
|
|
|
|
|
switch (name) {
|
|
|
|
case -1:
|
|
|
|
case 0:
|
|
|
|
break;
|
2021-09-29 16:11:06 +02:00
|
|
|
case 2:
|
2023-02-15 09:24:31 +01:00
|
|
|
if (c->mode != MODE_PASTA)
|
|
|
|
die("--userns is for pasta mode only");
|
2021-09-29 16:11:06 +02:00
|
|
|
|
|
|
|
ret = snprintf(userns, sizeof(userns), "%s", optarg);
|
2023-02-15 09:24:31 +01:00
|
|
|
if (ret <= 0 || ret >= (int)sizeof(userns))
|
|
|
|
die("Invalid userns: %s", optarg);
|
|
|
|
|
conf: Accept duplicate and conflicting options, the last one wins
In multiple occasions, especially when passt(1) and pasta(1) are used
in integrations such as the one with Podman, the ability to override
earlier options on the command line with later one would have been
convenient.
Recently, to debug a number of issues happening with Podman, I would
have liked to ask users to share a debug log by passing --debug as
additional option, but pasta refuses --quiet (always passed by Podman)
and --debug at the same time.
On top of this, Podman lets users specify other pasta options in its
containers.conf(5) file, as well as on the command line.
The options from the configuration files are appended together with
the ones from the command line, which makes it impossible for users to
override options from the configuration file, if duplicated options
are refused, unless Podman takes care of sorting them, which is
clearly not sustainable.
For --debug and --trace, somebody took care of this on Podman side at:
https://github.com/containers/common/pull/2052
but this doesn't fix the issue with other options, and we'll have
anyway older versions of Podman around, too.
I think there's some value in telling users about duplicated or
conflicting options, because that might reveal issues in integrations
or accidental misconfigurations, but by now I'm fairly convinced that
the downsides outweigh this.
Drop checks about duplicate options and mutually exclusive ones. In
some cases, we need to also undo a couple of initialisations caused
by earlier options, but this looks like a simplification, overall.
Notable exception: --stderr still conflicts with --log-file, because
users might have the expectation that they don't actually conflict.
But they do conflict in the existing implementation, so it's safer
to make sure that the users notice that.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 18:04:49 +02:00
|
|
|
netns_only = 0;
|
|
|
|
|
2021-09-29 16:11:06 +02:00
|
|
|
break;
|
2022-08-26 06:58:38 +02:00
|
|
|
case 3:
|
2023-02-15 09:24:31 +01:00
|
|
|
if (c->mode != MODE_PASTA)
|
|
|
|
die("--netns is for pasta mode only");
|
2022-08-26 06:58:38 +02:00
|
|
|
|
2023-02-15 09:24:35 +01:00
|
|
|
conf_netns_opt(netns, optarg);
|
2022-08-26 06:58:38 +02:00
|
|
|
break;
|
2021-10-11 12:01:31 +02:00
|
|
|
case 4:
|
2023-02-15 09:24:31 +01:00
|
|
|
if (c->mode != MODE_PASTA)
|
|
|
|
die("--ns-mac-addr is for pasta mode only");
|
2021-10-11 12:01:31 +02:00
|
|
|
|
2024-06-06 12:09:47 +02:00
|
|
|
parse_mac(c->mac_guest, optarg);
|
2021-10-11 12:01:31 +02:00
|
|
|
break;
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
case 5:
|
2023-02-15 09:24:31 +01:00
|
|
|
if (c->mode != MODE_PASTA)
|
|
|
|
die("--dhcp-dns is for pasta mode only");
|
|
|
|
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
c->no_dhcp_dns = 0;
|
|
|
|
break;
|
|
|
|
case 6:
|
2024-06-13 14:36:53 +02:00
|
|
|
if (c->mode == MODE_PASTA)
|
2023-02-15 09:24:31 +01:00
|
|
|
die("--no-dhcp-dns is for passt mode only");
|
|
|
|
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
c->no_dhcp_dns = 1;
|
|
|
|
break;
|
|
|
|
case 7:
|
2023-02-15 09:24:31 +01:00
|
|
|
if (c->mode != MODE_PASTA)
|
|
|
|
die("--dhcp-search is for pasta mode only");
|
|
|
|
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
c->no_dhcp_dns_search = 0;
|
|
|
|
break;
|
|
|
|
case 8:
|
2024-06-13 14:36:53 +02:00
|
|
|
if (c->mode == MODE_PASTA)
|
2023-02-15 09:24:31 +01:00
|
|
|
die("--no-dhcp-search is for passt mode only");
|
|
|
|
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
c->no_dhcp_dns_search = 1;
|
|
|
|
break;
|
|
|
|
case 9:
|
conf: Accept duplicate and conflicting options, the last one wins
In multiple occasions, especially when passt(1) and pasta(1) are used
in integrations such as the one with Podman, the ability to override
earlier options on the command line with later one would have been
convenient.
Recently, to debug a number of issues happening with Podman, I would
have liked to ask users to share a debug log by passing --debug as
additional option, but pasta refuses --quiet (always passed by Podman)
and --debug at the same time.
On top of this, Podman lets users specify other pasta options in its
containers.conf(5) file, as well as on the command line.
The options from the configuration files are appended together with
the ones from the command line, which makes it impossible for users to
override options from the configuration file, if duplicated options
are refused, unless Podman takes care of sorting them, which is
clearly not sustainable.
For --debug and --trace, somebody took care of this on Podman side at:
https://github.com/containers/common/pull/2052
but this doesn't fix the issue with other options, and we'll have
anyway older versions of Podman around, too.
I think there's some value in telling users about duplicated or
conflicting options, because that might reveal issues in integrations
or accidental misconfigurations, but by now I'm fairly convinced that
the downsides outweigh this.
Drop checks about duplicate options and mutually exclusive ones. In
some cases, we need to also undo a couple of initialisations caused
by earlier options, but this looks like a simplification, overall.
Notable exception: --stderr still conflicts with --log-file, because
users might have the expectation that they don't actually conflict.
But they do conflict in the existing implementation, so it's safer
to make sure that the users notice that.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 18:04:49 +02:00
|
|
|
if (inet_pton(AF_INET6, optarg, &c->ip6.dns_match) &&
|
conf, udp: Drop mostly duplicated dns_send arrays, rename related fields
Given that we use just the first valid DNS resolver address
configured, or read from resolv.conf(5) on the host, to forward DNS
queries to, in case --dns-forward is used, we don't need to duplicate
dns[] to dns_send[]:
- rename dns_send[] back to dns[]: those are the resolvers we
advertise to the guest/container
- for forwarding purposes, instead of dns[], use a single field (for
each protocol version): dns_host
- and rename dns_fwd to dns_match, so that it's clear this is the
address we are matching DNS queries against, to decide if they need
to be forwarded
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2022-11-10 20:30:03 +01:00
|
|
|
!IN6_IS_ADDR_UNSPECIFIED(&c->ip6.dns_match) &&
|
|
|
|
!IN6_IS_ADDR_LOOPBACK(&c->ip6.dns_match))
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
break;
|
|
|
|
|
conf: Accept duplicate and conflicting options, the last one wins
In multiple occasions, especially when passt(1) and pasta(1) are used
in integrations such as the one with Podman, the ability to override
earlier options on the command line with later one would have been
convenient.
Recently, to debug a number of issues happening with Podman, I would
have liked to ask users to share a debug log by passing --debug as
additional option, but pasta refuses --quiet (always passed by Podman)
and --debug at the same time.
On top of this, Podman lets users specify other pasta options in its
containers.conf(5) file, as well as on the command line.
The options from the configuration files are appended together with
the ones from the command line, which makes it impossible for users to
override options from the configuration file, if duplicated options
are refused, unless Podman takes care of sorting them, which is
clearly not sustainable.
For --debug and --trace, somebody took care of this on Podman side at:
https://github.com/containers/common/pull/2052
but this doesn't fix the issue with other options, and we'll have
anyway older versions of Podman around, too.
I think there's some value in telling users about duplicated or
conflicting options, because that might reveal issues in integrations
or accidental misconfigurations, but by now I'm fairly convinced that
the downsides outweigh this.
Drop checks about duplicate options and mutually exclusive ones. In
some cases, we need to also undo a couple of initialisations caused
by earlier options, but this looks like a simplification, overall.
Notable exception: --stderr still conflicts with --log-file, because
users might have the expectation that they don't actually conflict.
But they do conflict in the existing implementation, so it's safer
to make sure that the users notice that.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 18:04:49 +02:00
|
|
|
if (inet_pton(AF_INET, optarg, &c->ip4.dns_match) &&
|
conf, udp: Drop mostly duplicated dns_send arrays, rename related fields
Given that we use just the first valid DNS resolver address
configured, or read from resolv.conf(5) on the host, to forward DNS
queries to, in case --dns-forward is used, we don't need to duplicate
dns[] to dns_send[]:
- rename dns_send[] back to dns[]: those are the resolvers we
advertise to the guest/container
- for forwarding purposes, instead of dns[], use a single field (for
each protocol version): dns_host
- and rename dns_fwd to dns_match, so that it's clear this is the
address we are matching DNS queries against, to decide if they need
to be forwarded
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2022-11-10 20:30:03 +01:00
|
|
|
!IN4_IS_ADDR_UNSPECIFIED(&c->ip4.dns_match) &&
|
|
|
|
!IN4_IS_ADDR_BROADCAST(&c->ip4.dns_match) &&
|
|
|
|
!IN4_IS_ADDR_LOOPBACK(&c->ip4.dns_match))
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
break;
|
|
|
|
|
2023-02-15 09:24:31 +01:00
|
|
|
die("Invalid DNS forwarding address: %s", optarg);
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
break;
|
2022-02-18 16:12:11 +01:00
|
|
|
case 10:
|
2023-02-15 09:24:31 +01:00
|
|
|
if (c->mode != MODE_PASTA)
|
|
|
|
die("--no-netns-quit is for pasta mode only");
|
|
|
|
|
2022-02-18 16:12:11 +01:00
|
|
|
c->no_netns_quit = 1;
|
|
|
|
break;
|
2022-03-15 00:59:09 +01:00
|
|
|
case 11:
|
2022-10-26 16:48:42 +02:00
|
|
|
c->trace = c->debug = 1;
|
conf: Accept duplicate and conflicting options, the last one wins
In multiple occasions, especially when passt(1) and pasta(1) are used
in integrations such as the one with Podman, the ability to override
earlier options on the command line with later one would have been
convenient.
Recently, to debug a number of issues happening with Podman, I would
have liked to ask users to share a debug log by passing --debug as
additional option, but pasta refuses --quiet (always passed by Podman)
and --debug at the same time.
On top of this, Podman lets users specify other pasta options in its
containers.conf(5) file, as well as on the command line.
The options from the configuration files are appended together with
the ones from the command line, which makes it impossible for users to
override options from the configuration file, if duplicated options
are refused, unless Podman takes care of sorting them, which is
clearly not sustainable.
For --debug and --trace, somebody took care of this on Podman side at:
https://github.com/containers/common/pull/2052
but this doesn't fix the issue with other options, and we'll have
anyway older versions of Podman around, too.
I think there's some value in telling users about duplicated or
conflicting options, because that might reveal issues in integrations
or accidental misconfigurations, but by now I'm fairly convinced that
the downsides outweigh this.
Drop checks about duplicate options and mutually exclusive ones. In
some cases, we need to also undo a couple of initialisations caused
by earlier options, but this looks like a simplification, overall.
Notable exception: --stderr still conflicts with --log-file, because
users might have the expectation that they don't actually conflict.
But they do conflict in the existing implementation, so it's safer
to make sure that the users notice that.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 18:04:49 +02:00
|
|
|
c->quiet = 0;
|
2022-03-15 00:59:09 +01:00
|
|
|
break;
|
2022-05-18 19:10:45 +02:00
|
|
|
case 12:
|
2022-09-12 14:24:01 +02:00
|
|
|
runas = optarg;
|
2022-05-18 19:10:45 +02:00
|
|
|
break;
|
2022-10-06 14:51:04 +02:00
|
|
|
case 13:
|
|
|
|
errno = 0;
|
|
|
|
logsize = strtol(optarg, NULL, 0);
|
|
|
|
|
2023-02-15 09:24:31 +01:00
|
|
|
if (logsize < LOGFILE_SIZE_MIN || errno)
|
|
|
|
die("Invalid --log-size: %s", optarg);
|
|
|
|
|
2022-10-06 14:51:04 +02:00
|
|
|
break;
|
2022-10-10 10:35:47 +02:00
|
|
|
case 14:
|
|
|
|
fprintf(stdout,
|
2024-06-13 14:36:53 +02:00
|
|
|
c->mode == MODE_PASTA ? "pasta " : "passt ");
|
2022-10-10 10:35:47 +02:00
|
|
|
fprintf(stdout, VERSION_BLOB);
|
|
|
|
exit(EXIT_SUCCESS);
|
conf, icmp, tcp, udp: Add options to bind to outbound address and interface
I didn't notice earlier: libslirp (and slirp4netns) supports binding
outbound sockets to specific IPv4 and IPv6 addresses, to force the
source addresse selection. If we want to claim feature parity, we
should implement that as well.
Further, Podman supports specifying outbound interfaces as well, but
this is simply done by resolving the primary address for an interface
when the network back-end is started. However, since kernel version
5.7, commit c427bfec18f2 ("net: core: enable SO_BINDTODEVICE for
non-root users"), we can actually bind to a specific interface name,
which doesn't need to be validated in advance.
Implement -o / --outbound ADDR to bind to IPv4 and IPv6 addresses,
and --outbound-if4 and --outbound-if6 to bind IPv4 and IPv6 sockets
to given interfaces.
Given that it probably makes little sense to select addresses and
routes from interfaces different than the ones given for outbound
sockets, also assign those as "template" interfaces, by default,
unless explicitly overridden by '-i'.
For ICMP and UDP, we call sock_l4() to open outbound sockets, as we
already needed to bind to given ports or echo identifiers, and we
can bind() a socket only once: there, pass address (if any) and
interface (if any) for the existing bind() and setsockopt() calls.
For TCP, in general, we wouldn't otherwise bind sockets. Add a
specific helper to do that.
For UDP outbound sockets, we need to know if the final destination
of the socket is a loopback address, before we decide whether it
makes sense to bind the socket at all: move the block mangling the
address destination before the creation of the socket in the IPv4
path. This was already the case for the IPv6 path.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2023-03-08 03:29:51 +01:00
|
|
|
case 15:
|
|
|
|
ret = snprintf(c->ip4.ifname_out,
|
|
|
|
sizeof(c->ip4.ifname_out), "%s", optarg);
|
|
|
|
if (ret <= 0 || ret >= (int)sizeof(c->ip4.ifname_out))
|
|
|
|
die("Invalid interface name: %s", optarg);
|
|
|
|
|
|
|
|
break;
|
|
|
|
case 16:
|
|
|
|
ret = snprintf(c->ip6.ifname_out,
|
|
|
|
sizeof(c->ip6.ifname_out), "%s", optarg);
|
|
|
|
if (ret <= 0 || ret >= (int)sizeof(c->ip6.ifname_out))
|
|
|
|
die("Invalid interface name: %s", optarg);
|
|
|
|
|
2023-05-14 14:14:29 +02:00
|
|
|
break;
|
|
|
|
case 17:
|
|
|
|
if (c->mode != MODE_PASTA)
|
|
|
|
die("--config-net is for pasta mode only");
|
|
|
|
|
|
|
|
c->pasta_conf_ns = 1;
|
conf, icmp, tcp, udp: Add options to bind to outbound address and interface
I didn't notice earlier: libslirp (and slirp4netns) supports binding
outbound sockets to specific IPv4 and IPv6 addresses, to force the
source addresse selection. If we want to claim feature parity, we
should implement that as well.
Further, Podman supports specifying outbound interfaces as well, but
this is simply done by resolving the primary address for an interface
when the network back-end is started. However, since kernel version
5.7, commit c427bfec18f2 ("net: core: enable SO_BINDTODEVICE for
non-root users"), we can actually bind to a specific interface name,
which doesn't need to be validated in advance.
Implement -o / --outbound ADDR to bind to IPv4 and IPv6 addresses,
and --outbound-if4 and --outbound-if6 to bind IPv4 and IPv6 sockets
to given interfaces.
Given that it probably makes little sense to select addresses and
routes from interfaces different than the ones given for outbound
sockets, also assign those as "template" interfaces, by default,
unless explicitly overridden by '-i'.
For ICMP and UDP, we call sock_l4() to open outbound sockets, as we
already needed to bind to given ports or echo identifiers, and we
can bind() a socket only once: there, pass address (if any) and
interface (if any) for the existing bind() and setsockopt() calls.
For TCP, in general, we wouldn't otherwise bind sockets. Add a
specific helper to do that.
For UDP outbound sockets, we need to know if the final destination
of the socket is a loopback address, before we decide whether it
makes sense to bind the socket at all: move the block mangling the
address destination before the creation of the socket in the IPv4
path. This was already the case for the IPv6 path.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2023-03-08 03:29:51 +01:00
|
|
|
break;
|
2023-05-14 15:04:38 +02:00
|
|
|
case 18:
|
|
|
|
if (c->mode != MODE_PASTA)
|
|
|
|
die("--no-copy-routes is for pasta mode only");
|
|
|
|
|
|
|
|
warn("--no-copy-routes will be dropped soon");
|
2023-06-23 09:52:36 +02:00
|
|
|
c->no_copy_routes = copy_routes_opt = true;
|
2023-05-14 15:04:38 +02:00
|
|
|
break;
|
2023-05-14 19:12:09 +02:00
|
|
|
case 19:
|
|
|
|
if (c->mode != MODE_PASTA)
|
|
|
|
die("--no-copy-addrs is for pasta mode only");
|
|
|
|
|
|
|
|
warn("--no-copy-addrs will be dropped soon");
|
2023-06-23 09:52:36 +02:00
|
|
|
c->no_copy_addrs = copy_addrs_opt = true;
|
2023-05-14 19:12:09 +02:00
|
|
|
break;
|
conf: Accept duplicate and conflicting options, the last one wins
In multiple occasions, especially when passt(1) and pasta(1) are used
in integrations such as the one with Podman, the ability to override
earlier options on the command line with later one would have been
convenient.
Recently, to debug a number of issues happening with Podman, I would
have liked to ask users to share a debug log by passing --debug as
additional option, but pasta refuses --quiet (always passed by Podman)
and --debug at the same time.
On top of this, Podman lets users specify other pasta options in its
containers.conf(5) file, as well as on the command line.
The options from the configuration files are appended together with
the ones from the command line, which makes it impossible for users to
override options from the configuration file, if duplicated options
are refused, unless Podman takes care of sorting them, which is
clearly not sustainable.
For --debug and --trace, somebody took care of this on Podman side at:
https://github.com/containers/common/pull/2052
but this doesn't fix the issue with other options, and we'll have
anyway older versions of Podman around, too.
I think there's some value in telling users about duplicated or
conflicting options, because that might reveal issues in integrations
or accidental misconfigurations, but by now I'm fairly convinced that
the downsides outweigh this.
Drop checks about duplicate options and mutually exclusive ones. In
some cases, we need to also undo a couple of initialisations caused
by earlier options, but this looks like a simplification, overall.
Notable exception: --stderr still conflicts with --log-file, because
users might have the expectation that they don't actually conflict.
But they do conflict in the existing implementation, so it's safer
to make sure that the users notice that.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 18:04:49 +02:00
|
|
|
case 20:
|
|
|
|
if (c->mode != MODE_PASTA)
|
|
|
|
die("--netns-only is for pasta mode only");
|
2021-08-12 15:42:43 +02:00
|
|
|
|
conf: Accept duplicate and conflicting options, the last one wins
In multiple occasions, especially when passt(1) and pasta(1) are used
in integrations such as the one with Podman, the ability to override
earlier options on the command line with later one would have been
convenient.
Recently, to debug a number of issues happening with Podman, I would
have liked to ask users to share a debug log by passing --debug as
additional option, but pasta refuses --quiet (always passed by Podman)
and --debug at the same time.
On top of this, Podman lets users specify other pasta options in its
containers.conf(5) file, as well as on the command line.
The options from the configuration files are appended together with
the ones from the command line, which makes it impossible for users to
override options from the configuration file, if duplicated options
are refused, unless Podman takes care of sorting them, which is
clearly not sustainable.
For --debug and --trace, somebody took care of this on Podman side at:
https://github.com/containers/common/pull/2052
but this doesn't fix the issue with other options, and we'll have
anyway older versions of Podman around, too.
I think there's some value in telling users about duplicated or
conflicting options, because that might reveal issues in integrations
or accidental misconfigurations, but by now I'm fairly convinced that
the downsides outweigh this.
Drop checks about duplicate options and mutually exclusive ones. In
some cases, we need to also undo a couple of initialisations caused
by earlier options, but this looks like a simplification, overall.
Notable exception: --stderr still conflicts with --log-file, because
users might have the expectation that they don't actually conflict.
But they do conflict in the existing implementation, so it's safer
to make sure that the users notice that.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 18:04:49 +02:00
|
|
|
netns_only = 1;
|
|
|
|
*userns = 0;
|
|
|
|
break;
|
|
|
|
case 'd':
|
2021-08-12 15:42:43 +02:00
|
|
|
c->debug = 1;
|
conf: Accept duplicate and conflicting options, the last one wins
In multiple occasions, especially when passt(1) and pasta(1) are used
in integrations such as the one with Podman, the ability to override
earlier options on the command line with later one would have been
convenient.
Recently, to debug a number of issues happening with Podman, I would
have liked to ask users to share a debug log by passing --debug as
additional option, but pasta refuses --quiet (always passed by Podman)
and --debug at the same time.
On top of this, Podman lets users specify other pasta options in its
containers.conf(5) file, as well as on the command line.
The options from the configuration files are appended together with
the ones from the command line, which makes it impossible for users to
override options from the configuration file, if duplicated options
are refused, unless Podman takes care of sorting them, which is
clearly not sustainable.
For --debug and --trace, somebody took care of this on Podman side at:
https://github.com/containers/common/pull/2052
but this doesn't fix the issue with other options, and we'll have
anyway older versions of Podman around, too.
I think there's some value in telling users about duplicated or
conflicting options, because that might reveal issues in integrations
or accidental misconfigurations, but by now I'm fairly convinced that
the downsides outweigh this.
Drop checks about duplicate options and mutually exclusive ones. In
some cases, we need to also undo a couple of initialisations caused
by earlier options, but this looks like a simplification, overall.
Notable exception: --stderr still conflicts with --log-file, because
users might have the expectation that they don't actually conflict.
But they do conflict in the existing implementation, so it's safer
to make sure that the users notice that.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 18:04:49 +02:00
|
|
|
c->quiet = 0;
|
2021-08-12 15:42:43 +02:00
|
|
|
break;
|
2022-01-27 16:42:19 +01:00
|
|
|
case 'e':
|
conf, passt: Make --stderr do nothing, and deprecate it
The original behaviour of printing messages to standard error by
default when running from a non-interactive terminal was introduced
because the first KubeVirt integration draft used to start passt in
foreground and get messages via standard error.
For development purposes, the system logger was more convenient at
that point, and passt was running from interactive terminals only if
not started by the KubeVirt integration.
This behaviour was introduced by 84a62b79a2bc ("passt: Also log to
stderr, don't fork to background if not interactive").
Later, I added command-line options in 1e49d194d017 ("passt, pasta:
Introduce command-line options and port re-mapping") and accidentally
reversed this condition, which wasn't a problem as --stderr could
force printing to standard error anyway (and it was used by KubeVirt).
Nowadays, the KubeVirt integration uses a log file (requested via
libvirt configuration), and the same applies for Podman if one
actually needs to look at runtime logs. There are no use cases left,
as far as I know, where passt runs in foreground in non-interactive
terminals.
Seize the chance to reintroduce some sanity here. If we fork to
background, standard error is closed, so --stderr is useless in that
case.
If we run in foreground, there's no harm in printing messages to
standard error, and that accidentally became the default behaviour
anyway, so --stderr is not needed in that case.
It would be needed for non-interactive terminals, but there are no
use cases, and if there were, let's log to standard error anyway:
the user can always redirect standard error to /dev/null if needed.
Before we're up and running, we need to print to standard error anyway
if something happens, otherwise we can't report failure to start in
any kind of usage, stand-alone or in integrations.
So, make --stderr do nothing, and deprecate it.
While at it, drop a left-over comment about --foreground being the
default only for interactive terminals, because it's not the case
anymore.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2024-06-19 20:10:10 +02:00
|
|
|
warn("--stderr will be dropped soon");
|
2022-01-27 16:42:19 +01:00
|
|
|
break;
|
2022-10-06 14:51:04 +02:00
|
|
|
case 'l':
|
|
|
|
logfile = optarg;
|
|
|
|
break;
|
2021-08-12 15:42:43 +02:00
|
|
|
case 'q':
|
|
|
|
c->quiet = 1;
|
conf: Accept duplicate and conflicting options, the last one wins
In multiple occasions, especially when passt(1) and pasta(1) are used
in integrations such as the one with Podman, the ability to override
earlier options on the command line with later one would have been
convenient.
Recently, to debug a number of issues happening with Podman, I would
have liked to ask users to share a debug log by passing --debug as
additional option, but pasta refuses --quiet (always passed by Podman)
and --debug at the same time.
On top of this, Podman lets users specify other pasta options in its
containers.conf(5) file, as well as on the command line.
The options from the configuration files are appended together with
the ones from the command line, which makes it impossible for users to
override options from the configuration file, if duplicated options
are refused, unless Podman takes care of sorting them, which is
clearly not sustainable.
For --debug and --trace, somebody took care of this on Podman side at:
https://github.com/containers/common/pull/2052
but this doesn't fix the issue with other options, and we'll have
anyway older versions of Podman around, too.
I think there's some value in telling users about duplicated or
conflicting options, because that might reveal issues in integrations
or accidental misconfigurations, but by now I'm fairly convinced that
the downsides outweigh this.
Drop checks about duplicate options and mutually exclusive ones. In
some cases, we need to also undo a couple of initialisations caused
by earlier options, but this looks like a simplification, overall.
Notable exception: --stderr still conflicts with --log-file, because
users might have the expectation that they don't actually conflict.
But they do conflict in the existing implementation, so it's safer
to make sure that the users notice that.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 18:04:49 +02:00
|
|
|
c->debug = c->trace = 0;
|
2021-08-12 15:42:43 +02:00
|
|
|
break;
|
|
|
|
case 'f':
|
|
|
|
c->foreground = 1;
|
|
|
|
break;
|
|
|
|
case 's':
|
2022-04-05 12:33:31 +02:00
|
|
|
ret = snprintf(c->sock_path, UNIX_SOCK_MAX - 1, "%s",
|
2021-08-12 15:42:43 +02:00
|
|
|
optarg);
|
2023-02-15 09:24:31 +01:00
|
|
|
if (ret <= 0 || ret >= (int)sizeof(c->sock_path))
|
|
|
|
die("Invalid socket path: %s", optarg);
|
|
|
|
|
conf: Accept duplicate and conflicting options, the last one wins
In multiple occasions, especially when passt(1) and pasta(1) are used
in integrations such as the one with Podman, the ability to override
earlier options on the command line with later one would have been
convenient.
Recently, to debug a number of issues happening with Podman, I would
have liked to ask users to share a debug log by passing --debug as
additional option, but pasta refuses --quiet (always passed by Podman)
and --debug at the same time.
On top of this, Podman lets users specify other pasta options in its
containers.conf(5) file, as well as on the command line.
The options from the configuration files are appended together with
the ones from the command line, which makes it impossible for users to
override options from the configuration file, if duplicated options
are refused, unless Podman takes care of sorting them, which is
clearly not sustainable.
For --debug and --trace, somebody took care of this on Podman side at:
https://github.com/containers/common/pull/2052
but this doesn't fix the issue with other options, and we'll have
anyway older versions of Podman around, too.
I think there's some value in telling users about duplicated or
conflicting options, because that might reveal issues in integrations
or accidental misconfigurations, but by now I'm fairly convinced that
the downsides outweigh this.
Drop checks about duplicate options and mutually exclusive ones. In
some cases, we need to also undo a couple of initialisations caused
by earlier options, but this looks like a simplification, overall.
Notable exception: --stderr still conflicts with --log-file, because
users might have the expectation that they don't actually conflict.
But they do conflict in the existing implementation, so it's safer
to make sure that the users notice that.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 18:04:49 +02:00
|
|
|
c->fd_tap = -1;
|
2022-11-17 19:49:34 +01:00
|
|
|
break;
|
|
|
|
case 'F':
|
|
|
|
errno = 0;
|
|
|
|
c->fd_tap = strtol(optarg, NULL, 0);
|
|
|
|
|
2023-02-15 09:24:31 +01:00
|
|
|
if (c->fd_tap < 0 || errno)
|
|
|
|
die("Invalid --fd: %s", optarg);
|
2022-11-17 19:49:34 +01:00
|
|
|
|
|
|
|
c->one_off = true;
|
conf: Accept duplicate and conflicting options, the last one wins
In multiple occasions, especially when passt(1) and pasta(1) are used
in integrations such as the one with Podman, the ability to override
earlier options on the command line with later one would have been
convenient.
Recently, to debug a number of issues happening with Podman, I would
have liked to ask users to share a debug log by passing --debug as
additional option, but pasta refuses --quiet (always passed by Podman)
and --debug at the same time.
On top of this, Podman lets users specify other pasta options in its
containers.conf(5) file, as well as on the command line.
The options from the configuration files are appended together with
the ones from the command line, which makes it impossible for users to
override options from the configuration file, if duplicated options
are refused, unless Podman takes care of sorting them, which is
clearly not sustainable.
For --debug and --trace, somebody took care of this on Podman side at:
https://github.com/containers/common/pull/2052
but this doesn't fix the issue with other options, and we'll have
anyway older versions of Podman around, too.
I think there's some value in telling users about duplicated or
conflicting options, because that might reveal issues in integrations
or accidental misconfigurations, but by now I'm fairly convinced that
the downsides outweigh this.
Drop checks about duplicate options and mutually exclusive ones. In
some cases, we need to also undo a couple of initialisations caused
by earlier options, but this looks like a simplification, overall.
Notable exception: --stderr still conflicts with --log-file, because
users might have the expectation that they don't actually conflict.
But they do conflict in the existing implementation, so it's safer
to make sure that the users notice that.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 18:04:49 +02:00
|
|
|
*c->sock_path = 0;
|
2021-08-12 15:42:43 +02:00
|
|
|
break;
|
|
|
|
case 'I':
|
2023-06-28 07:11:14 +02:00
|
|
|
ret = snprintf(c->pasta_ifn, IFNAMSIZ, "%s",
|
2021-08-12 15:42:43 +02:00
|
|
|
optarg);
|
2023-06-28 07:11:14 +02:00
|
|
|
if (ret <= 0 || ret >= IFNAMSIZ)
|
2023-02-15 09:24:31 +01:00
|
|
|
die("Invalid interface name: %s", optarg);
|
|
|
|
|
2021-08-12 15:42:43 +02:00
|
|
|
break;
|
|
|
|
case 'p':
|
|
|
|
ret = snprintf(c->pcap, sizeof(c->pcap), "%s", optarg);
|
2023-02-15 09:24:31 +01:00
|
|
|
if (ret <= 0 || ret >= (int)sizeof(c->pcap))
|
|
|
|
die("Invalid pcap path: %s", optarg);
|
|
|
|
|
2021-08-12 15:42:43 +02:00
|
|
|
break;
|
2021-10-14 12:17:47 +02:00
|
|
|
case 'P':
|
2024-05-22 20:39:30 +02:00
|
|
|
ret = snprintf(c->pidfile, sizeof(c->pidfile), "%s",
|
2021-10-14 12:17:47 +02:00
|
|
|
optarg);
|
2024-05-22 20:39:30 +02:00
|
|
|
if (ret <= 0 || ret >= (int)sizeof(c->pidfile))
|
2023-02-15 09:24:31 +01:00
|
|
|
die("Invalid PID file: %s", optarg);
|
|
|
|
|
2021-10-14 12:17:47 +02:00
|
|
|
break;
|
2021-08-12 15:42:43 +02:00
|
|
|
case 'm':
|
|
|
|
errno = 0;
|
|
|
|
c->mtu = strtol(optarg, NULL, 0);
|
2021-09-07 11:19:57 +02:00
|
|
|
|
|
|
|
if (!c->mtu) {
|
|
|
|
c->mtu = -1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2021-08-12 15:42:43 +02:00
|
|
|
if (c->mtu < ETH_MIN_MTU || c->mtu > (int)ETH_MAX_MTU ||
|
2023-02-15 09:24:31 +01:00
|
|
|
errno)
|
|
|
|
die("Invalid MTU: %s", optarg);
|
|
|
|
|
2021-08-12 15:42:43 +02:00
|
|
|
break;
|
|
|
|
case 'a':
|
2023-06-22 15:46:41 +02:00
|
|
|
if (c->mode == MODE_PASTA)
|
|
|
|
c->no_copy_addrs = 1;
|
|
|
|
|
conf: Accept duplicate and conflicting options, the last one wins
In multiple occasions, especially when passt(1) and pasta(1) are used
in integrations such as the one with Podman, the ability to override
earlier options on the command line with later one would have been
convenient.
Recently, to debug a number of issues happening with Podman, I would
have liked to ask users to share a debug log by passing --debug as
additional option, but pasta refuses --quiet (always passed by Podman)
and --debug at the same time.
On top of this, Podman lets users specify other pasta options in its
containers.conf(5) file, as well as on the command line.
The options from the configuration files are appended together with
the ones from the command line, which makes it impossible for users to
override options from the configuration file, if duplicated options
are refused, unless Podman takes care of sorting them, which is
clearly not sustainable.
For --debug and --trace, somebody took care of this on Podman side at:
https://github.com/containers/common/pull/2052
but this doesn't fix the issue with other options, and we'll have
anyway older versions of Podman around, too.
I think there's some value in telling users about duplicated or
conflicting options, because that might reveal issues in integrations
or accidental misconfigurations, but by now I'm fairly convinced that
the downsides outweigh this.
Drop checks about duplicate options and mutually exclusive ones. In
some cases, we need to also undo a couple of initialisations caused
by earlier options, but this looks like a simplification, overall.
Notable exception: --stderr still conflicts with --log-file, because
users might have the expectation that they don't actually conflict.
But they do conflict in the existing implementation, so it's safer
to make sure that the users notice that.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 18:04:49 +02:00
|
|
|
if (inet_pton(AF_INET6, optarg, &c->ip6.addr) &&
|
2022-07-22 07:31:18 +02:00
|
|
|
!IN6_IS_ADDR_UNSPECIFIED(&c->ip6.addr) &&
|
|
|
|
!IN6_IS_ADDR_LOOPBACK(&c->ip6.addr) &&
|
|
|
|
!IN6_IS_ADDR_V4MAPPED(&c->ip6.addr) &&
|
|
|
|
!IN6_IS_ADDR_V4COMPAT(&c->ip6.addr) &&
|
|
|
|
!IN6_IS_ADDR_MULTICAST(&c->ip6.addr))
|
2021-08-12 15:42:43 +02:00
|
|
|
break;
|
|
|
|
|
conf: Accept duplicate and conflicting options, the last one wins
In multiple occasions, especially when passt(1) and pasta(1) are used
in integrations such as the one with Podman, the ability to override
earlier options on the command line with later one would have been
convenient.
Recently, to debug a number of issues happening with Podman, I would
have liked to ask users to share a debug log by passing --debug as
additional option, but pasta refuses --quiet (always passed by Podman)
and --debug at the same time.
On top of this, Podman lets users specify other pasta options in its
containers.conf(5) file, as well as on the command line.
The options from the configuration files are appended together with
the ones from the command line, which makes it impossible for users to
override options from the configuration file, if duplicated options
are refused, unless Podman takes care of sorting them, which is
clearly not sustainable.
For --debug and --trace, somebody took care of this on Podman side at:
https://github.com/containers/common/pull/2052
but this doesn't fix the issue with other options, and we'll have
anyway older versions of Podman around, too.
I think there's some value in telling users about duplicated or
conflicting options, because that might reveal issues in integrations
or accidental misconfigurations, but by now I'm fairly convinced that
the downsides outweigh this.
Drop checks about duplicate options and mutually exclusive ones. In
some cases, we need to also undo a couple of initialisations caused
by earlier options, but this looks like a simplification, overall.
Notable exception: --stderr still conflicts with --log-file, because
users might have the expectation that they don't actually conflict.
But they do conflict in the existing implementation, so it's safer
to make sure that the users notice that.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 18:04:49 +02:00
|
|
|
if (inet_pton(AF_INET, optarg, &c->ip4.addr) &&
|
2022-11-04 04:10:35 +01:00
|
|
|
!IN4_IS_ADDR_UNSPECIFIED(&c->ip4.addr) &&
|
|
|
|
!IN4_IS_ADDR_BROADCAST(&c->ip4.addr) &&
|
|
|
|
!IN4_IS_ADDR_LOOPBACK(&c->ip4.addr) &&
|
|
|
|
!IN4_IS_ADDR_MULTICAST(&c->ip4.addr))
|
2021-08-12 15:42:43 +02:00
|
|
|
break;
|
|
|
|
|
2023-02-15 09:24:31 +01:00
|
|
|
die("Invalid address: %s", optarg);
|
2021-08-12 15:42:43 +02:00
|
|
|
break;
|
|
|
|
case 'n':
|
2022-11-04 04:10:33 +01:00
|
|
|
c->ip4.prefix_len = conf_ip4_prefix(optarg);
|
2023-02-15 09:24:31 +01:00
|
|
|
if (c->ip4.prefix_len < 0)
|
|
|
|
die("Invalid netmask: %s", optarg);
|
|
|
|
|
2021-08-12 15:42:43 +02:00
|
|
|
break;
|
|
|
|
case 'M':
|
2024-06-06 12:09:47 +02:00
|
|
|
parse_mac(c->mac, optarg);
|
2021-08-12 15:42:43 +02:00
|
|
|
break;
|
|
|
|
case 'g':
|
2023-05-14 15:04:38 +02:00
|
|
|
if (c->mode == MODE_PASTA)
|
|
|
|
c->no_copy_routes = 1;
|
|
|
|
|
conf: Accept duplicate and conflicting options, the last one wins
In multiple occasions, especially when passt(1) and pasta(1) are used
in integrations such as the one with Podman, the ability to override
earlier options on the command line with later one would have been
convenient.
Recently, to debug a number of issues happening with Podman, I would
have liked to ask users to share a debug log by passing --debug as
additional option, but pasta refuses --quiet (always passed by Podman)
and --debug at the same time.
On top of this, Podman lets users specify other pasta options in its
containers.conf(5) file, as well as on the command line.
The options from the configuration files are appended together with
the ones from the command line, which makes it impossible for users to
override options from the configuration file, if duplicated options
are refused, unless Podman takes care of sorting them, which is
clearly not sustainable.
For --debug and --trace, somebody took care of this on Podman side at:
https://github.com/containers/common/pull/2052
but this doesn't fix the issue with other options, and we'll have
anyway older versions of Podman around, too.
I think there's some value in telling users about duplicated or
conflicting options, because that might reveal issues in integrations
or accidental misconfigurations, but by now I'm fairly convinced that
the downsides outweigh this.
Drop checks about duplicate options and mutually exclusive ones. In
some cases, we need to also undo a couple of initialisations caused
by earlier options, but this looks like a simplification, overall.
Notable exception: --stderr still conflicts with --log-file, because
users might have the expectation that they don't actually conflict.
But they do conflict in the existing implementation, so it's safer
to make sure that the users notice that.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 18:04:49 +02:00
|
|
|
if (inet_pton(AF_INET6, optarg, &c->ip6.gw) &&
|
2022-07-22 07:31:18 +02:00
|
|
|
!IN6_IS_ADDR_UNSPECIFIED(&c->ip6.gw) &&
|
|
|
|
!IN6_IS_ADDR_LOOPBACK(&c->ip6.gw))
|
2021-08-12 15:42:43 +02:00
|
|
|
break;
|
|
|
|
|
conf: Accept duplicate and conflicting options, the last one wins
In multiple occasions, especially when passt(1) and pasta(1) are used
in integrations such as the one with Podman, the ability to override
earlier options on the command line with later one would have been
convenient.
Recently, to debug a number of issues happening with Podman, I would
have liked to ask users to share a debug log by passing --debug as
additional option, but pasta refuses --quiet (always passed by Podman)
and --debug at the same time.
On top of this, Podman lets users specify other pasta options in its
containers.conf(5) file, as well as on the command line.
The options from the configuration files are appended together with
the ones from the command line, which makes it impossible for users to
override options from the configuration file, if duplicated options
are refused, unless Podman takes care of sorting them, which is
clearly not sustainable.
For --debug and --trace, somebody took care of this on Podman side at:
https://github.com/containers/common/pull/2052
but this doesn't fix the issue with other options, and we'll have
anyway older versions of Podman around, too.
I think there's some value in telling users about duplicated or
conflicting options, because that might reveal issues in integrations
or accidental misconfigurations, but by now I'm fairly convinced that
the downsides outweigh this.
Drop checks about duplicate options and mutually exclusive ones. In
some cases, we need to also undo a couple of initialisations caused
by earlier options, but this looks like a simplification, overall.
Notable exception: --stderr still conflicts with --log-file, because
users might have the expectation that they don't actually conflict.
But they do conflict in the existing implementation, so it's safer
to make sure that the users notice that.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 18:04:49 +02:00
|
|
|
if (inet_pton(AF_INET, optarg, &c->ip4.gw) &&
|
2022-11-04 04:10:35 +01:00
|
|
|
!IN4_IS_ADDR_UNSPECIFIED(&c->ip4.gw) &&
|
|
|
|
!IN4_IS_ADDR_BROADCAST(&c->ip4.gw) &&
|
|
|
|
!IN4_IS_ADDR_LOOPBACK(&c->ip4.gw))
|
2021-08-12 15:42:43 +02:00
|
|
|
break;
|
|
|
|
|
2023-02-15 09:24:31 +01:00
|
|
|
die("Invalid gateway address: %s", optarg);
|
2021-08-12 15:42:43 +02:00
|
|
|
break;
|
|
|
|
case 'i':
|
conf, icmp, tcp, udp: Add options to bind to outbound address and interface
I didn't notice earlier: libslirp (and slirp4netns) supports binding
outbound sockets to specific IPv4 and IPv6 addresses, to force the
source addresse selection. If we want to claim feature parity, we
should implement that as well.
Further, Podman supports specifying outbound interfaces as well, but
this is simply done by resolving the primary address for an interface
when the network back-end is started. However, since kernel version
5.7, commit c427bfec18f2 ("net: core: enable SO_BINDTODEVICE for
non-root users"), we can actually bind to a specific interface name,
which doesn't need to be validated in advance.
Implement -o / --outbound ADDR to bind to IPv4 and IPv6 addresses,
and --outbound-if4 and --outbound-if6 to bind IPv4 and IPv6 sockets
to given interfaces.
Given that it probably makes little sense to select addresses and
routes from interfaces different than the ones given for outbound
sockets, also assign those as "template" interfaces, by default,
unless explicitly overridden by '-i'.
For ICMP and UDP, we call sock_l4() to open outbound sockets, as we
already needed to bind to given ports or echo identifiers, and we
can bind() a socket only once: there, pass address (if any) and
interface (if any) for the existing bind() and setsockopt() calls.
For TCP, in general, we wouldn't otherwise bind sockets. Add a
specific helper to do that.
For UDP outbound sockets, we need to know if the final destination
of the socket is a loopback address, before we decide whether it
makes sense to bind the socket at all: move the block mangling the
address destination before the creation of the socket in the IPv4
path. This was already the case for the IPv6 path.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2023-03-08 03:29:51 +01:00
|
|
|
if (!(ifi4 = ifi6 = if_nametoindex(optarg)))
|
2023-02-15 09:24:31 +01:00
|
|
|
die("Invalid interface name %s: %s", optarg,
|
2021-10-11 12:01:31 +02:00
|
|
|
strerror(errno));
|
2021-08-12 15:42:43 +02:00
|
|
|
break;
|
conf, icmp, tcp, udp: Add options to bind to outbound address and interface
I didn't notice earlier: libslirp (and slirp4netns) supports binding
outbound sockets to specific IPv4 and IPv6 addresses, to force the
source addresse selection. If we want to claim feature parity, we
should implement that as well.
Further, Podman supports specifying outbound interfaces as well, but
this is simply done by resolving the primary address for an interface
when the network back-end is started. However, since kernel version
5.7, commit c427bfec18f2 ("net: core: enable SO_BINDTODEVICE for
non-root users"), we can actually bind to a specific interface name,
which doesn't need to be validated in advance.
Implement -o / --outbound ADDR to bind to IPv4 and IPv6 addresses,
and --outbound-if4 and --outbound-if6 to bind IPv4 and IPv6 sockets
to given interfaces.
Given that it probably makes little sense to select addresses and
routes from interfaces different than the ones given for outbound
sockets, also assign those as "template" interfaces, by default,
unless explicitly overridden by '-i'.
For ICMP and UDP, we call sock_l4() to open outbound sockets, as we
already needed to bind to given ports or echo identifiers, and we
can bind() a socket only once: there, pass address (if any) and
interface (if any) for the existing bind() and setsockopt() calls.
For TCP, in general, we wouldn't otherwise bind sockets. Add a
specific helper to do that.
For UDP outbound sockets, we need to know if the final destination
of the socket is a loopback address, before we decide whether it
makes sense to bind the socket at all: move the block mangling the
address destination before the creation of the socket in the IPv4
path. This was already the case for the IPv6 path.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2023-03-08 03:29:51 +01:00
|
|
|
case 'o':
|
conf: Accept duplicate and conflicting options, the last one wins
In multiple occasions, especially when passt(1) and pasta(1) are used
in integrations such as the one with Podman, the ability to override
earlier options on the command line with later one would have been
convenient.
Recently, to debug a number of issues happening with Podman, I would
have liked to ask users to share a debug log by passing --debug as
additional option, but pasta refuses --quiet (always passed by Podman)
and --debug at the same time.
On top of this, Podman lets users specify other pasta options in its
containers.conf(5) file, as well as on the command line.
The options from the configuration files are appended together with
the ones from the command line, which makes it impossible for users to
override options from the configuration file, if duplicated options
are refused, unless Podman takes care of sorting them, which is
clearly not sustainable.
For --debug and --trace, somebody took care of this on Podman side at:
https://github.com/containers/common/pull/2052
but this doesn't fix the issue with other options, and we'll have
anyway older versions of Podman around, too.
I think there's some value in telling users about duplicated or
conflicting options, because that might reveal issues in integrations
or accidental misconfigurations, but by now I'm fairly convinced that
the downsides outweigh this.
Drop checks about duplicate options and mutually exclusive ones. In
some cases, we need to also undo a couple of initialisations caused
by earlier options, but this looks like a simplification, overall.
Notable exception: --stderr still conflicts with --log-file, because
users might have the expectation that they don't actually conflict.
But they do conflict in the existing implementation, so it's safer
to make sure that the users notice that.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 18:04:49 +02:00
|
|
|
if (inet_pton(AF_INET6, optarg, &c->ip6.addr_out) &&
|
conf, icmp, tcp, udp: Add options to bind to outbound address and interface
I didn't notice earlier: libslirp (and slirp4netns) supports binding
outbound sockets to specific IPv4 and IPv6 addresses, to force the
source addresse selection. If we want to claim feature parity, we
should implement that as well.
Further, Podman supports specifying outbound interfaces as well, but
this is simply done by resolving the primary address for an interface
when the network back-end is started. However, since kernel version
5.7, commit c427bfec18f2 ("net: core: enable SO_BINDTODEVICE for
non-root users"), we can actually bind to a specific interface name,
which doesn't need to be validated in advance.
Implement -o / --outbound ADDR to bind to IPv4 and IPv6 addresses,
and --outbound-if4 and --outbound-if6 to bind IPv4 and IPv6 sockets
to given interfaces.
Given that it probably makes little sense to select addresses and
routes from interfaces different than the ones given for outbound
sockets, also assign those as "template" interfaces, by default,
unless explicitly overridden by '-i'.
For ICMP and UDP, we call sock_l4() to open outbound sockets, as we
already needed to bind to given ports or echo identifiers, and we
can bind() a socket only once: there, pass address (if any) and
interface (if any) for the existing bind() and setsockopt() calls.
For TCP, in general, we wouldn't otherwise bind sockets. Add a
specific helper to do that.
For UDP outbound sockets, we need to know if the final destination
of the socket is a loopback address, before we decide whether it
makes sense to bind the socket at all: move the block mangling the
address destination before the creation of the socket in the IPv4
path. This was already the case for the IPv6 path.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2023-03-08 03:29:51 +01:00
|
|
|
!IN6_IS_ADDR_UNSPECIFIED(&c->ip6.addr_out) &&
|
|
|
|
!IN6_IS_ADDR_LOOPBACK(&c->ip6.addr_out) &&
|
|
|
|
!IN6_IS_ADDR_V4MAPPED(&c->ip6.addr_out) &&
|
|
|
|
!IN6_IS_ADDR_V4COMPAT(&c->ip6.addr_out) &&
|
|
|
|
!IN6_IS_ADDR_MULTICAST(&c->ip6.addr_out))
|
|
|
|
break;
|
|
|
|
|
conf: Accept duplicate and conflicting options, the last one wins
In multiple occasions, especially when passt(1) and pasta(1) are used
in integrations such as the one with Podman, the ability to override
earlier options on the command line with later one would have been
convenient.
Recently, to debug a number of issues happening with Podman, I would
have liked to ask users to share a debug log by passing --debug as
additional option, but pasta refuses --quiet (always passed by Podman)
and --debug at the same time.
On top of this, Podman lets users specify other pasta options in its
containers.conf(5) file, as well as on the command line.
The options from the configuration files are appended together with
the ones from the command line, which makes it impossible for users to
override options from the configuration file, if duplicated options
are refused, unless Podman takes care of sorting them, which is
clearly not sustainable.
For --debug and --trace, somebody took care of this on Podman side at:
https://github.com/containers/common/pull/2052
but this doesn't fix the issue with other options, and we'll have
anyway older versions of Podman around, too.
I think there's some value in telling users about duplicated or
conflicting options, because that might reveal issues in integrations
or accidental misconfigurations, but by now I'm fairly convinced that
the downsides outweigh this.
Drop checks about duplicate options and mutually exclusive ones. In
some cases, we need to also undo a couple of initialisations caused
by earlier options, but this looks like a simplification, overall.
Notable exception: --stderr still conflicts with --log-file, because
users might have the expectation that they don't actually conflict.
But they do conflict in the existing implementation, so it's safer
to make sure that the users notice that.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 18:04:49 +02:00
|
|
|
if (inet_pton(AF_INET, optarg, &c->ip4.addr_out) &&
|
conf, icmp, tcp, udp: Add options to bind to outbound address and interface
I didn't notice earlier: libslirp (and slirp4netns) supports binding
outbound sockets to specific IPv4 and IPv6 addresses, to force the
source addresse selection. If we want to claim feature parity, we
should implement that as well.
Further, Podman supports specifying outbound interfaces as well, but
this is simply done by resolving the primary address for an interface
when the network back-end is started. However, since kernel version
5.7, commit c427bfec18f2 ("net: core: enable SO_BINDTODEVICE for
non-root users"), we can actually bind to a specific interface name,
which doesn't need to be validated in advance.
Implement -o / --outbound ADDR to bind to IPv4 and IPv6 addresses,
and --outbound-if4 and --outbound-if6 to bind IPv4 and IPv6 sockets
to given interfaces.
Given that it probably makes little sense to select addresses and
routes from interfaces different than the ones given for outbound
sockets, also assign those as "template" interfaces, by default,
unless explicitly overridden by '-i'.
For ICMP and UDP, we call sock_l4() to open outbound sockets, as we
already needed to bind to given ports or echo identifiers, and we
can bind() a socket only once: there, pass address (if any) and
interface (if any) for the existing bind() and setsockopt() calls.
For TCP, in general, we wouldn't otherwise bind sockets. Add a
specific helper to do that.
For UDP outbound sockets, we need to know if the final destination
of the socket is a loopback address, before we decide whether it
makes sense to bind the socket at all: move the block mangling the
address destination before the creation of the socket in the IPv4
path. This was already the case for the IPv6 path.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2023-03-08 03:29:51 +01:00
|
|
|
!IN4_IS_ADDR_UNSPECIFIED(&c->ip4.addr_out) &&
|
|
|
|
!IN4_IS_ADDR_BROADCAST(&c->ip4.addr_out) &&
|
|
|
|
!IN4_IS_ADDR_MULTICAST(&c->ip4.addr_out))
|
|
|
|
break;
|
|
|
|
|
|
|
|
die("Invalid or redundant outbound address: %s",
|
|
|
|
optarg);
|
|
|
|
break;
|
2021-08-12 15:42:43 +02:00
|
|
|
case 'D':
|
2022-08-26 06:58:33 +02:00
|
|
|
if (!strcmp(optarg, "none")) {
|
conf: Accept duplicate and conflicting options, the last one wins
In multiple occasions, especially when passt(1) and pasta(1) are used
in integrations such as the one with Podman, the ability to override
earlier options on the command line with later one would have been
convenient.
Recently, to debug a number of issues happening with Podman, I would
have liked to ask users to share a debug log by passing --debug as
additional option, but pasta refuses --quiet (always passed by Podman)
and --debug at the same time.
On top of this, Podman lets users specify other pasta options in its
containers.conf(5) file, as well as on the command line.
The options from the configuration files are appended together with
the ones from the command line, which makes it impossible for users to
override options from the configuration file, if duplicated options
are refused, unless Podman takes care of sorting them, which is
clearly not sustainable.
For --debug and --trace, somebody took care of this on Podman side at:
https://github.com/containers/common/pull/2052
but this doesn't fix the issue with other options, and we'll have
anyway older versions of Podman around, too.
I think there's some value in telling users about duplicated or
conflicting options, because that might reveal issues in integrations
or accidental misconfigurations, but by now I'm fairly convinced that
the downsides outweigh this.
Drop checks about duplicate options and mutually exclusive ones. In
some cases, we need to also undo a couple of initialisations caused
by earlier options, but this looks like a simplification, overall.
Notable exception: --stderr still conflicts with --log-file, because
users might have the expectation that they don't actually conflict.
But they do conflict in the existing implementation, so it's safer
to make sure that the users notice that.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 18:04:49 +02:00
|
|
|
c->no_dns = 1;
|
2022-08-26 06:58:33 +02:00
|
|
|
|
conf: Accept duplicate and conflicting options, the last one wins
In multiple occasions, especially when passt(1) and pasta(1) are used
in integrations such as the one with Podman, the ability to override
earlier options on the command line with later one would have been
convenient.
Recently, to debug a number of issues happening with Podman, I would
have liked to ask users to share a debug log by passing --debug as
additional option, but pasta refuses --quiet (always passed by Podman)
and --debug at the same time.
On top of this, Podman lets users specify other pasta options in its
containers.conf(5) file, as well as on the command line.
The options from the configuration files are appended together with
the ones from the command line, which makes it impossible for users to
override options from the configuration file, if duplicated options
are refused, unless Podman takes care of sorting them, which is
clearly not sustainable.
For --debug and --trace, somebody took care of this on Podman side at:
https://github.com/containers/common/pull/2052
but this doesn't fix the issue with other options, and we'll have
anyway older versions of Podman around, too.
I think there's some value in telling users about duplicated or
conflicting options, because that might reveal issues in integrations
or accidental misconfigurations, but by now I'm fairly convinced that
the downsides outweigh this.
Drop checks about duplicate options and mutually exclusive ones. In
some cases, we need to also undo a couple of initialisations caused
by earlier options, but this looks like a simplification, overall.
Notable exception: --stderr still conflicts with --log-file, because
users might have the expectation that they don't actually conflict.
But they do conflict in the existing implementation, so it's safer
to make sure that the users notice that.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 18:04:49 +02:00
|
|
|
dns4 = &c->ip4.dns[0];
|
|
|
|
memset(c->ip4.dns, 0, sizeof(c->ip4.dns));
|
|
|
|
c->ip4.dns[0] = (struct in_addr){ 0 };
|
|
|
|
c->ip4.dns_match = (struct in_addr){ 0 };
|
|
|
|
c->ip4.dns_host = (struct in_addr){ 0 };
|
|
|
|
|
|
|
|
dns6 = &c->ip6.dns[0];
|
|
|
|
memset(c->ip6.dns, 0, sizeof(c->ip6.dns));
|
|
|
|
c->ip6.dns_match = (struct in6_addr){ 0 };
|
|
|
|
c->ip6.dns_host = (struct in6_addr){ 0 };
|
2021-08-12 15:42:43 +02:00
|
|
|
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
conf: Accept duplicate and conflicting options, the last one wins
In multiple occasions, especially when passt(1) and pasta(1) are used
in integrations such as the one with Podman, the ability to override
earlier options on the command line with later one would have been
convenient.
Recently, to debug a number of issues happening with Podman, I would
have liked to ask users to share a debug log by passing --debug as
additional option, but pasta refuses --quiet (always passed by Podman)
and --debug at the same time.
On top of this, Podman lets users specify other pasta options in its
containers.conf(5) file, as well as on the command line.
The options from the configuration files are appended together with
the ones from the command line, which makes it impossible for users to
override options from the configuration file, if duplicated options
are refused, unless Podman takes care of sorting them, which is
clearly not sustainable.
For --debug and --trace, somebody took care of this on Podman side at:
https://github.com/containers/common/pull/2052
but this doesn't fix the issue with other options, and we'll have
anyway older versions of Podman around, too.
I think there's some value in telling users about duplicated or
conflicting options, because that might reveal issues in integrations
or accidental misconfigurations, but by now I'm fairly convinced that
the downsides outweigh this.
Drop checks about duplicate options and mutually exclusive ones. In
some cases, we need to also undo a couple of initialisations caused
by earlier options, but this looks like a simplification, overall.
Notable exception: --stderr still conflicts with --log-file, because
users might have the expectation that they don't actually conflict.
But they do conflict in the existing implementation, so it's safer
to make sure that the users notice that.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 18:04:49 +02:00
|
|
|
c->no_dns = 0;
|
2022-08-26 06:58:33 +02:00
|
|
|
|
2022-07-22 07:31:18 +02:00
|
|
|
if (dns4 - &c->ip4.dns[0] < ARRAY_SIZE(c->ip4.dns) &&
|
2024-03-12 01:51:56 +01:00
|
|
|
inet_pton(AF_INET, optarg, &dns4_tmp)) {
|
|
|
|
add_dns4(c, &dns4_tmp, &dns4);
|
2021-08-12 15:42:43 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2022-07-22 07:31:18 +02:00
|
|
|
if (dns6 - &c->ip6.dns[0] < ARRAY_SIZE(c->ip6.dns) &&
|
2024-03-12 01:51:56 +01:00
|
|
|
inet_pton(AF_INET6, optarg, &dns6_tmp)) {
|
|
|
|
add_dns6(c, &dns6_tmp, &dns6);
|
2021-08-12 15:42:43 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2023-02-15 09:24:31 +01:00
|
|
|
die("Cannot use DNS address %s", optarg);
|
2021-08-12 15:42:43 +02:00
|
|
|
break;
|
|
|
|
case 'S':
|
2022-08-26 06:58:33 +02:00
|
|
|
if (!strcmp(optarg, "none")) {
|
conf: Accept duplicate and conflicting options, the last one wins
In multiple occasions, especially when passt(1) and pasta(1) are used
in integrations such as the one with Podman, the ability to override
earlier options on the command line with later one would have been
convenient.
Recently, to debug a number of issues happening with Podman, I would
have liked to ask users to share a debug log by passing --debug as
additional option, but pasta refuses --quiet (always passed by Podman)
and --debug at the same time.
On top of this, Podman lets users specify other pasta options in its
containers.conf(5) file, as well as on the command line.
The options from the configuration files are appended together with
the ones from the command line, which makes it impossible for users to
override options from the configuration file, if duplicated options
are refused, unless Podman takes care of sorting them, which is
clearly not sustainable.
For --debug and --trace, somebody took care of this on Podman side at:
https://github.com/containers/common/pull/2052
but this doesn't fix the issue with other options, and we'll have
anyway older versions of Podman around, too.
I think there's some value in telling users about duplicated or
conflicting options, because that might reveal issues in integrations
or accidental misconfigurations, but by now I'm fairly convinced that
the downsides outweigh this.
Drop checks about duplicate options and mutually exclusive ones. In
some cases, we need to also undo a couple of initialisations caused
by earlier options, but this looks like a simplification, overall.
Notable exception: --stderr still conflicts with --log-file, because
users might have the expectation that they don't actually conflict.
But they do conflict in the existing implementation, so it's safer
to make sure that the users notice that.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 18:04:49 +02:00
|
|
|
c->no_dns_search = 1;
|
2022-08-26 06:58:33 +02:00
|
|
|
|
conf: Accept duplicate and conflicting options, the last one wins
In multiple occasions, especially when passt(1) and pasta(1) are used
in integrations such as the one with Podman, the ability to override
earlier options on the command line with later one would have been
convenient.
Recently, to debug a number of issues happening with Podman, I would
have liked to ask users to share a debug log by passing --debug as
additional option, but pasta refuses --quiet (always passed by Podman)
and --debug at the same time.
On top of this, Podman lets users specify other pasta options in its
containers.conf(5) file, as well as on the command line.
The options from the configuration files are appended together with
the ones from the command line, which makes it impossible for users to
override options from the configuration file, if duplicated options
are refused, unless Podman takes care of sorting them, which is
clearly not sustainable.
For --debug and --trace, somebody took care of this on Podman side at:
https://github.com/containers/common/pull/2052
but this doesn't fix the issue with other options, and we'll have
anyway older versions of Podman around, too.
I think there's some value in telling users about duplicated or
conflicting options, because that might reveal issues in integrations
or accidental misconfigurations, but by now I'm fairly convinced that
the downsides outweigh this.
Drop checks about duplicate options and mutually exclusive ones. In
some cases, we need to also undo a couple of initialisations caused
by earlier options, but this looks like a simplification, overall.
Notable exception: --stderr still conflicts with --log-file, because
users might have the expectation that they don't actually conflict.
But they do conflict in the existing implementation, so it's safer
to make sure that the users notice that.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 18:04:49 +02:00
|
|
|
memset(c->dns_search, 0, sizeof(c->dns_search));
|
2021-08-12 15:42:43 +02:00
|
|
|
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
conf: Accept duplicate and conflicting options, the last one wins
In multiple occasions, especially when passt(1) and pasta(1) are used
in integrations such as the one with Podman, the ability to override
earlier options on the command line with later one would have been
convenient.
Recently, to debug a number of issues happening with Podman, I would
have liked to ask users to share a debug log by passing --debug as
additional option, but pasta refuses --quiet (always passed by Podman)
and --debug at the same time.
On top of this, Podman lets users specify other pasta options in its
containers.conf(5) file, as well as on the command line.
The options from the configuration files are appended together with
the ones from the command line, which makes it impossible for users to
override options from the configuration file, if duplicated options
are refused, unless Podman takes care of sorting them, which is
clearly not sustainable.
For --debug and --trace, somebody took care of this on Podman side at:
https://github.com/containers/common/pull/2052
but this doesn't fix the issue with other options, and we'll have
anyway older versions of Podman around, too.
I think there's some value in telling users about duplicated or
conflicting options, because that might reveal issues in integrations
or accidental misconfigurations, but by now I'm fairly convinced that
the downsides outweigh this.
Drop checks about duplicate options and mutually exclusive ones. In
some cases, we need to also undo a couple of initialisations caused
by earlier options, but this looks like a simplification, overall.
Notable exception: --stderr still conflicts with --log-file, because
users might have the expectation that they don't actually conflict.
But they do conflict in the existing implementation, so it's safer
to make sure that the users notice that.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 18:04:49 +02:00
|
|
|
c->no_dns_search = 0;
|
2022-08-26 06:58:33 +02:00
|
|
|
|
2021-08-12 15:42:43 +02:00
|
|
|
if (dnss - c->dns_search < ARRAY_SIZE(c->dns_search)) {
|
|
|
|
ret = snprintf(dnss->n, sizeof(*c->dns_search),
|
|
|
|
"%s", optarg);
|
|
|
|
dnss++;
|
|
|
|
|
|
|
|
if (ret > 0 &&
|
|
|
|
ret < (int)sizeof(*c->dns_search))
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2023-02-15 09:24:31 +01:00
|
|
|
die("Cannot use DNS search domain %s", optarg);
|
2021-08-12 15:42:43 +02:00
|
|
|
break;
|
|
|
|
case '4':
|
2022-07-22 07:31:16 +02:00
|
|
|
v4_only = true;
|
conf: Accept duplicate and conflicting options, the last one wins
In multiple occasions, especially when passt(1) and pasta(1) are used
in integrations such as the one with Podman, the ability to override
earlier options on the command line with later one would have been
convenient.
Recently, to debug a number of issues happening with Podman, I would
have liked to ask users to share a debug log by passing --debug as
additional option, but pasta refuses --quiet (always passed by Podman)
and --debug at the same time.
On top of this, Podman lets users specify other pasta options in its
containers.conf(5) file, as well as on the command line.
The options from the configuration files are appended together with
the ones from the command line, which makes it impossible for users to
override options from the configuration file, if duplicated options
are refused, unless Podman takes care of sorting them, which is
clearly not sustainable.
For --debug and --trace, somebody took care of this on Podman side at:
https://github.com/containers/common/pull/2052
but this doesn't fix the issue with other options, and we'll have
anyway older versions of Podman around, too.
I think there's some value in telling users about duplicated or
conflicting options, because that might reveal issues in integrations
or accidental misconfigurations, but by now I'm fairly convinced that
the downsides outweigh this.
Drop checks about duplicate options and mutually exclusive ones. In
some cases, we need to also undo a couple of initialisations caused
by earlier options, but this looks like a simplification, overall.
Notable exception: --stderr still conflicts with --log-file, because
users might have the expectation that they don't actually conflict.
But they do conflict in the existing implementation, so it's safer
to make sure that the users notice that.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 18:04:49 +02:00
|
|
|
v6_only = false;
|
2021-08-12 15:42:43 +02:00
|
|
|
break;
|
|
|
|
case '6':
|
2022-07-22 07:31:16 +02:00
|
|
|
v6_only = true;
|
conf: Accept duplicate and conflicting options, the last one wins
In multiple occasions, especially when passt(1) and pasta(1) are used
in integrations such as the one with Podman, the ability to override
earlier options on the command line with later one would have been
convenient.
Recently, to debug a number of issues happening with Podman, I would
have liked to ask users to share a debug log by passing --debug as
additional option, but pasta refuses --quiet (always passed by Podman)
and --debug at the same time.
On top of this, Podman lets users specify other pasta options in its
containers.conf(5) file, as well as on the command line.
The options from the configuration files are appended together with
the ones from the command line, which makes it impossible for users to
override options from the configuration file, if duplicated options
are refused, unless Podman takes care of sorting them, which is
clearly not sustainable.
For --debug and --trace, somebody took care of this on Podman side at:
https://github.com/containers/common/pull/2052
but this doesn't fix the issue with other options, and we'll have
anyway older versions of Podman around, too.
I think there's some value in telling users about duplicated or
conflicting options, because that might reveal issues in integrations
or accidental misconfigurations, but by now I'm fairly convinced that
the downsides outweigh this.
Drop checks about duplicate options and mutually exclusive ones. In
some cases, we need to also undo a couple of initialisations caused
by earlier options, but this looks like a simplification, overall.
Notable exception: --stderr still conflicts with --log-file, because
users might have the expectation that they don't actually conflict.
But they do conflict in the existing implementation, so it's safer
to make sure that the users notice that.
Suggested-by: Paul Holzinger <pholzing@redhat.com>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 18:04:49 +02:00
|
|
|
v4_only = false;
|
2021-08-12 15:42:43 +02:00
|
|
|
break;
|
2022-10-07 04:01:56 +02:00
|
|
|
case '1':
|
2024-06-13 14:36:53 +02:00
|
|
|
if (c->mode == MODE_PASTA)
|
2023-02-15 09:24:31 +01:00
|
|
|
die("--one-off is for passt mode only");
|
2022-10-07 04:01:56 +02:00
|
|
|
|
|
|
|
c->one_off = true;
|
|
|
|
break;
|
2021-08-12 15:42:43 +02:00
|
|
|
case 't':
|
|
|
|
case 'u':
|
|
|
|
case 'T':
|
|
|
|
case 'U':
|
2022-05-01 06:36:34 +02:00
|
|
|
/* Handle these later, once addresses are configured */
|
2021-08-12 15:42:43 +02:00
|
|
|
break;
|
2021-10-20 00:05:11 +02:00
|
|
|
case 'h':
|
2024-06-05 02:42:41 +02:00
|
|
|
usage(argv[0], stdout, EXIT_SUCCESS);
|
2023-06-04 07:14:49 +02:00
|
|
|
break;
|
|
|
|
case '?':
|
2021-10-20 00:05:11 +02:00
|
|
|
default:
|
2024-06-05 02:42:41 +02:00
|
|
|
usage(argv[0], stderr, EXIT_FAILURE);
|
2021-10-20 00:05:11 +02:00
|
|
|
break;
|
2021-08-12 15:42:43 +02:00
|
|
|
}
|
|
|
|
} while (name != -1);
|
2022-11-17 19:49:34 +01:00
|
|
|
|
2023-05-14 19:12:09 +02:00
|
|
|
if (c->mode == MODE_PASTA && !c->pasta_conf_ns) {
|
2023-06-23 09:52:36 +02:00
|
|
|
if (copy_routes_opt)
|
|
|
|
die("--no-copy-routes needs --config-net");
|
|
|
|
if (copy_addrs_opt)
|
|
|
|
die("--no-copy-addrs needs --config-net");
|
2023-05-14 19:12:09 +02:00
|
|
|
}
|
2023-05-14 15:04:38 +02:00
|
|
|
|
conf, icmp, tcp, udp: Add options to bind to outbound address and interface
I didn't notice earlier: libslirp (and slirp4netns) supports binding
outbound sockets to specific IPv4 and IPv6 addresses, to force the
source addresse selection. If we want to claim feature parity, we
should implement that as well.
Further, Podman supports specifying outbound interfaces as well, but
this is simply done by resolving the primary address for an interface
when the network back-end is started. However, since kernel version
5.7, commit c427bfec18f2 ("net: core: enable SO_BINDTODEVICE for
non-root users"), we can actually bind to a specific interface name,
which doesn't need to be validated in advance.
Implement -o / --outbound ADDR to bind to IPv4 and IPv6 addresses,
and --outbound-if4 and --outbound-if6 to bind IPv4 and IPv6 sockets
to given interfaces.
Given that it probably makes little sense to select addresses and
routes from interfaces different than the ones given for outbound
sockets, also assign those as "template" interfaces, by default,
unless explicitly overridden by '-i'.
For ICMP and UDP, we call sock_l4() to open outbound sockets, as we
already needed to bind to given ports or echo identifiers, and we
can bind() a socket only once: there, pass address (if any) and
interface (if any) for the existing bind() and setsockopt() calls.
For TCP, in general, we wouldn't otherwise bind sockets. Add a
specific helper to do that.
For UDP outbound sockets, we need to know if the final destination
of the socket is a loopback address, before we decide whether it
makes sense to bind the socket at all: move the block mangling the
address destination before the creation of the socket in the IPv4
path. This was already the case for the IPv6 path.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2023-03-08 03:29:51 +01:00
|
|
|
if (!ifi4 && *c->ip4.ifname_out)
|
|
|
|
ifi4 = if_nametoindex(c->ip4.ifname_out);
|
|
|
|
|
|
|
|
if (!ifi6 && *c->ip6.ifname_out)
|
|
|
|
ifi6 = if_nametoindex(c->ip6.ifname_out);
|
|
|
|
|
2023-02-15 09:24:34 +01:00
|
|
|
conf_ugid(runas, &uid, &gid);
|
2022-09-12 14:24:01 +02:00
|
|
|
|
2022-10-06 14:51:04 +02:00
|
|
|
if (logfile) {
|
2024-06-13 14:36:53 +02:00
|
|
|
logfile_init(c->mode == MODE_PASTA ? "pasta" : "passt",
|
2022-10-06 14:51:04 +02:00
|
|
|
logfile, logsize);
|
|
|
|
}
|
|
|
|
|
2024-02-22 18:17:41 +01:00
|
|
|
/* Once the log mask is not LOG_EARLY, we will no longer log to stderr
|
|
|
|
* if there was a log file specified.
|
|
|
|
*/
|
|
|
|
if (c->debug)
|
|
|
|
__setlogmask(LOG_UPTO(LOG_DEBUG));
|
|
|
|
else if (c->quiet)
|
|
|
|
__setlogmask(LOG_UPTO(LOG_WARNING));
|
|
|
|
else
|
|
|
|
__setlogmask(LOG_UPTO(LOG_INFO));
|
|
|
|
|
conf: Bind inbound ports with CAP_NET_BIND_SERVICE before isolate_user()
Even if CAP_NET_BIND_SERVICE is granted, we'll lose the capability in
the target user namespace as we isolate the process, which means
we're unable to bind to low ports at that point.
Bind inbound ports, and only those, before isolate_user(). Keep the
handling of outbound ports (for pasta mode only) after the setup of
the namespace, because that's where we'll bind them.
To this end, initialise the netlink socket for the init namespace
before isolate_user() as well, as we actually need to know the
addresses of the upstream interface before binding ports, in case
they're not explicitly passed by the user.
As we now call nl_sock_init() twice, checking its return code from
conf() twice looks a bit heavy: make it exit(), instead, as we
can't do much if we don't have netlink sockets.
While at it:
- move the v4_only && v6_only options check just after the first
option processing loop, as this is more strictly related to
option parsing proper
- update the man page, explaining that CAP_NET_BIND_SERVICE is
*not* the preferred way to bind ports, because passt and pasta
can be abused to allow other processes to make effective usage
of it. Add a note about the recommended sysctl instead
- simplify nl_sock_init_do() now that it's called once for each
case
Reported-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-10-13 18:21:27 +02:00
|
|
|
nl_sock_init(c, false);
|
|
|
|
if (!v6_only)
|
conf, icmp, tcp, udp: Add options to bind to outbound address and interface
I didn't notice earlier: libslirp (and slirp4netns) supports binding
outbound sockets to specific IPv4 and IPv6 addresses, to force the
source addresse selection. If we want to claim feature parity, we
should implement that as well.
Further, Podman supports specifying outbound interfaces as well, but
this is simply done by resolving the primary address for an interface
when the network back-end is started. However, since kernel version
5.7, commit c427bfec18f2 ("net: core: enable SO_BINDTODEVICE for
non-root users"), we can actually bind to a specific interface name,
which doesn't need to be validated in advance.
Implement -o / --outbound ADDR to bind to IPv4 and IPv6 addresses,
and --outbound-if4 and --outbound-if6 to bind IPv4 and IPv6 sockets
to given interfaces.
Given that it probably makes little sense to select addresses and
routes from interfaces different than the ones given for outbound
sockets, also assign those as "template" interfaces, by default,
unless explicitly overridden by '-i'.
For ICMP and UDP, we call sock_l4() to open outbound sockets, as we
already needed to bind to given ports or echo identifiers, and we
can bind() a socket only once: there, pass address (if any) and
interface (if any) for the existing bind() and setsockopt() calls.
For TCP, in general, we wouldn't otherwise bind sockets. Add a
specific helper to do that.
For UDP outbound sockets, we need to know if the final destination
of the socket is a loopback address, before we decide whether it
makes sense to bind the socket at all: move the block mangling the
address destination before the creation of the socket in the IPv4
path. This was already the case for the IPv6 path.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2023-03-08 03:29:51 +01:00
|
|
|
c->ifi4 = conf_ip4(ifi4, &c->ip4, c->mac);
|
conf: Bind inbound ports with CAP_NET_BIND_SERVICE before isolate_user()
Even if CAP_NET_BIND_SERVICE is granted, we'll lose the capability in
the target user namespace as we isolate the process, which means
we're unable to bind to low ports at that point.
Bind inbound ports, and only those, before isolate_user(). Keep the
handling of outbound ports (for pasta mode only) after the setup of
the namespace, because that's where we'll bind them.
To this end, initialise the netlink socket for the init namespace
before isolate_user() as well, as we actually need to know the
addresses of the upstream interface before binding ports, in case
they're not explicitly passed by the user.
As we now call nl_sock_init() twice, checking its return code from
conf() twice looks a bit heavy: make it exit(), instead, as we
can't do much if we don't have netlink sockets.
While at it:
- move the v4_only && v6_only options check just after the first
option processing loop, as this is more strictly related to
option parsing proper
- update the man page, explaining that CAP_NET_BIND_SERVICE is
*not* the preferred way to bind ports, because passt and pasta
can be abused to allow other processes to make effective usage
of it. Add a note about the recommended sysctl instead
- simplify nl_sock_init_do() now that it's called once for each
case
Reported-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-10-13 18:21:27 +02:00
|
|
|
if (!v4_only)
|
conf, icmp, tcp, udp: Add options to bind to outbound address and interface
I didn't notice earlier: libslirp (and slirp4netns) supports binding
outbound sockets to specific IPv4 and IPv6 addresses, to force the
source addresse selection. If we want to claim feature parity, we
should implement that as well.
Further, Podman supports specifying outbound interfaces as well, but
this is simply done by resolving the primary address for an interface
when the network back-end is started. However, since kernel version
5.7, commit c427bfec18f2 ("net: core: enable SO_BINDTODEVICE for
non-root users"), we can actually bind to a specific interface name,
which doesn't need to be validated in advance.
Implement -o / --outbound ADDR to bind to IPv4 and IPv6 addresses,
and --outbound-if4 and --outbound-if6 to bind IPv4 and IPv6 sockets
to given interfaces.
Given that it probably makes little sense to select addresses and
routes from interfaces different than the ones given for outbound
sockets, also assign those as "template" interfaces, by default,
unless explicitly overridden by '-i'.
For ICMP and UDP, we call sock_l4() to open outbound sockets, as we
already needed to bind to given ports or echo identifiers, and we
can bind() a socket only once: there, pass address (if any) and
interface (if any) for the existing bind() and setsockopt() calls.
For TCP, in general, we wouldn't otherwise bind sockets. Add a
specific helper to do that.
For UDP outbound sockets, we need to know if the final destination
of the socket is a loopback address, before we decide whether it
makes sense to bind the socket at all: move the block mangling the
address destination before the creation of the socket in the IPv4
path. This was already the case for the IPv6 path.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2023-03-08 03:29:51 +01:00
|
|
|
c->ifi6 = conf_ip6(ifi6, &c->ip6, c->mac);
|
|
|
|
if ((!c->ifi4 && !c->ifi6) ||
|
|
|
|
(*c->ip4.ifname_out && !c->ifi4) ||
|
|
|
|
(*c->ip6.ifname_out && !c->ifi6))
|
2023-02-15 09:24:31 +01:00
|
|
|
die("External interface not usable");
|
conf: Bind inbound ports with CAP_NET_BIND_SERVICE before isolate_user()
Even if CAP_NET_BIND_SERVICE is granted, we'll lose the capability in
the target user namespace as we isolate the process, which means
we're unable to bind to low ports at that point.
Bind inbound ports, and only those, before isolate_user(). Keep the
handling of outbound ports (for pasta mode only) after the setup of
the namespace, because that's where we'll bind them.
To this end, initialise the netlink socket for the init namespace
before isolate_user() as well, as we actually need to know the
addresses of the upstream interface before binding ports, in case
they're not explicitly passed by the user.
As we now call nl_sock_init() twice, checking its return code from
conf() twice looks a bit heavy: make it exit(), instead, as we
can't do much if we don't have netlink sockets.
While at it:
- move the v4_only && v6_only options check just after the first
option processing loop, as this is more strictly related to
option parsing proper
- update the man page, explaining that CAP_NET_BIND_SERVICE is
*not* the preferred way to bind ports, because passt and pasta
can be abused to allow other processes to make effective usage
of it. Add a note about the recommended sysctl instead
- simplify nl_sock_init_do() now that it's called once for each
case
Reported-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-10-13 18:21:27 +02:00
|
|
|
|
conf: Don't exit if sourced default route has no gateway
If we use a template interface without a gateway on the default
route, we can still offer almost complete functionality, except that,
of course, we can't map the gateway address to the outer namespace or
host, and that we have no obvious server address or identifier for
use in DHCP's siaddr and option 54 (Server identifier, mandatory).
Continue, if we have a default route but no default gateway, and
imply --no-map-gw and --no-dhcp in that case. NDP responder and
DHCPv6 should be able to work as usual because we require a
link-local address to be present, and we'll fall back to that.
Together with the previous commits implementing an actual copy of
routes from the outer namespace, this should finally fix the
operation of 'pasta --config-net' for cases where we have a default
route on the host, but no default gateway, as it's the case for
tap-style routes, including typical Wireguard endpoints.
Reported-by: me@yawnt.com
Link: https://bugs.passt.top/show_bug.cgi?id=49
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2023-05-14 16:24:11 +02:00
|
|
|
if (c->ifi4 && IN4_IS_ADDR_UNSPECIFIED(&c->ip4.gw))
|
|
|
|
c->no_map_gw = c->no_dhcp = 1;
|
|
|
|
|
|
|
|
if (c->ifi6 && IN6_IS_ADDR_UNSPECIFIED(&c->ip6.gw))
|
|
|
|
c->no_map_gw = 1;
|
|
|
|
|
conf: Bind inbound ports with CAP_NET_BIND_SERVICE before isolate_user()
Even if CAP_NET_BIND_SERVICE is granted, we'll lose the capability in
the target user namespace as we isolate the process, which means
we're unable to bind to low ports at that point.
Bind inbound ports, and only those, before isolate_user(). Keep the
handling of outbound ports (for pasta mode only) after the setup of
the namespace, because that's where we'll bind them.
To this end, initialise the netlink socket for the init namespace
before isolate_user() as well, as we actually need to know the
addresses of the upstream interface before binding ports, in case
they're not explicitly passed by the user.
As we now call nl_sock_init() twice, checking its return code from
conf() twice looks a bit heavy: make it exit(), instead, as we
can't do much if we don't have netlink sockets.
While at it:
- move the v4_only && v6_only options check just after the first
option processing loop, as this is more strictly related to
option parsing proper
- update the man page, explaining that CAP_NET_BIND_SERVICE is
*not* the preferred way to bind ports, because passt and pasta
can be abused to allow other processes to make effective usage
of it. Add a note about the recommended sysctl instead
- simplify nl_sock_init_do() now that it's called once for each
case
Reported-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-10-13 18:21:27 +02:00
|
|
|
/* Inbound port options can be parsed now (after IPv4/IPv6 settings) */
|
2023-11-06 03:17:08 +01:00
|
|
|
udp_portmap_clear();
|
conf: Bind inbound ports with CAP_NET_BIND_SERVICE before isolate_user()
Even if CAP_NET_BIND_SERVICE is granted, we'll lose the capability in
the target user namespace as we isolate the process, which means
we're unable to bind to low ports at that point.
Bind inbound ports, and only those, before isolate_user(). Keep the
handling of outbound ports (for pasta mode only) after the setup of
the namespace, because that's where we'll bind them.
To this end, initialise the netlink socket for the init namespace
before isolate_user() as well, as we actually need to know the
addresses of the upstream interface before binding ports, in case
they're not explicitly passed by the user.
As we now call nl_sock_init() twice, checking its return code from
conf() twice looks a bit heavy: make it exit(), instead, as we
can't do much if we don't have netlink sockets.
While at it:
- move the v4_only && v6_only options check just after the first
option processing loop, as this is more strictly related to
option parsing proper
- update the man page, explaining that CAP_NET_BIND_SERVICE is
*not* the preferred way to bind ports, because passt and pasta
can be abused to allow other processes to make effective usage
of it. Add a note about the recommended sysctl instead
- simplify nl_sock_init_do() now that it's called once for each
case
Reported-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-10-13 18:21:27 +02:00
|
|
|
optind = 1;
|
|
|
|
do {
|
|
|
|
name = getopt_long(argc, argv, optstring, options, NULL);
|
|
|
|
|
2023-09-29 07:50:20 +02:00
|
|
|
if (name == 't')
|
|
|
|
conf_ports(c, name, optarg, &c->tcp.fwd_in);
|
|
|
|
else if (name == 'u')
|
|
|
|
conf_ports(c, name, optarg, &c->udp.fwd_in.f);
|
conf: Bind inbound ports with CAP_NET_BIND_SERVICE before isolate_user()
Even if CAP_NET_BIND_SERVICE is granted, we'll lose the capability in
the target user namespace as we isolate the process, which means
we're unable to bind to low ports at that point.
Bind inbound ports, and only those, before isolate_user(). Keep the
handling of outbound ports (for pasta mode only) after the setup of
the namespace, because that's where we'll bind them.
To this end, initialise the netlink socket for the init namespace
before isolate_user() as well, as we actually need to know the
addresses of the upstream interface before binding ports, in case
they're not explicitly passed by the user.
As we now call nl_sock_init() twice, checking its return code from
conf() twice looks a bit heavy: make it exit(), instead, as we
can't do much if we don't have netlink sockets.
While at it:
- move the v4_only && v6_only options check just after the first
option processing loop, as this is more strictly related to
option parsing proper
- update the man page, explaining that CAP_NET_BIND_SERVICE is
*not* the preferred way to bind ports, because passt and pasta
can be abused to allow other processes to make effective usage
of it. Add a note about the recommended sysctl instead
- simplify nl_sock_init_do() now that it's called once for each
case
Reported-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-10-13 18:21:27 +02:00
|
|
|
} while (name != -1);
|
|
|
|
|
2023-02-15 09:24:33 +01:00
|
|
|
if (c->mode == MODE_PASTA)
|
|
|
|
conf_pasta_ns(&netns_only, userns, netns, optind, argc, argv);
|
|
|
|
else if (optind != argc)
|
2023-02-15 09:24:36 +01:00
|
|
|
die("Extra non-option argument: %s", argv[optind]);
|
2021-08-12 15:42:43 +02:00
|
|
|
|
2024-05-22 20:18:19 +02:00
|
|
|
conf_open_files(c); /* Before any possible setuid() / setgid() */
|
|
|
|
|
2022-10-14 06:25:34 +02:00
|
|
|
isolate_user(uid, gid, !netns_only, userns, c->mode);
|
2022-09-12 14:24:07 +02:00
|
|
|
|
2022-02-23 10:51:46 +01:00
|
|
|
if (c->pasta_conf_ns)
|
|
|
|
c->no_ra = 1;
|
|
|
|
|
More deterministic detection of whether argument is a PID, PATH or NAME
pasta takes as its only non-option argument either a PID to attach to the
namespaces of, a PATH to a network namespace or a NAME of a network
namespace (relative to /run/netns). Currently to determine which it is
we try all 3 in that order, and if anything goes wrong we move onto the
next.
This has the potential to cause very confusing failure modes. e.g. if the
argument is intended to be a network namespace name, but a (non-namespace)
file of the same name exists in the current directory.
Make behaviour more predictable by choosing how to treat the argument based
only on the argument's contents, not anything else on the system:
- If it's a decimal integer treat it as a PID
- Otherwise, if it has no '/' characters, treat it as a netns name
(ip-netns doesn't allow '/' in netns names)
- Otherwise, treat it as a netns path
If you want to open a persistent netns in the current directory, you can
use './netns'.
This also allows us to split the parsing of the PID|PATH|NAME option from
the actual opening of the namespaces. In turn that allows us to put the
opening of existing namespaces next to the opening of new namespaces in
pasta_start_ns. That makes the logical flow easier to follow and will
enable later cleanups.
Caveats:
- The separation of functions mean we will always generate the basename
and dirname for the netns_quit system, even when using PID namespaces.
This is pointless, since the netns_quit system doesn't work for non
persistent namespaces, but is harmless.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-08-26 06:58:37 +02:00
|
|
|
if (c->mode == MODE_PASTA) {
|
|
|
|
if (*netns) {
|
2022-09-12 14:24:07 +02:00
|
|
|
pasta_open_ns(c, netns);
|
More deterministic detection of whether argument is a PID, PATH or NAME
pasta takes as its only non-option argument either a PID to attach to the
namespaces of, a PATH to a network namespace or a NAME of a network
namespace (relative to /run/netns). Currently to determine which it is
we try all 3 in that order, and if anything goes wrong we move onto the
next.
This has the potential to cause very confusing failure modes. e.g. if the
argument is intended to be a network namespace name, but a (non-namespace)
file of the same name exists in the current directory.
Make behaviour more predictable by choosing how to treat the argument based
only on the argument's contents, not anything else on the system:
- If it's a decimal integer treat it as a PID
- Otherwise, if it has no '/' characters, treat it as a netns name
(ip-netns doesn't allow '/' in netns names)
- Otherwise, treat it as a netns path
If you want to open a persistent netns in the current directory, you can
use './netns'.
This also allows us to split the parsing of the PID|PATH|NAME option from
the actual opening of the namespaces. In turn that allows us to put the
opening of existing namespaces next to the opening of new namespaces in
pasta_start_ns. That makes the logical flow easier to follow and will
enable later cleanups.
Caveats:
- The separation of functions mean we will always generate the basename
and dirname for the netns_quit system, even when using PID namespaces.
This is pointless, since the netns_quit system doesn't work for non
persistent namespaces, but is harmless.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-08-26 06:58:37 +02:00
|
|
|
} else {
|
2022-10-14 06:25:36 +02:00
|
|
|
pasta_start_ns(c, uid, gid,
|
|
|
|
argc - optind, argv + optind);
|
More deterministic detection of whether argument is a PID, PATH or NAME
pasta takes as its only non-option argument either a PID to attach to the
namespaces of, a PATH to a network namespace or a NAME of a network
namespace (relative to /run/netns). Currently to determine which it is
we try all 3 in that order, and if anything goes wrong we move onto the
next.
This has the potential to cause very confusing failure modes. e.g. if the
argument is intended to be a network namespace name, but a (non-namespace)
file of the same name exists in the current directory.
Make behaviour more predictable by choosing how to treat the argument based
only on the argument's contents, not anything else on the system:
- If it's a decimal integer treat it as a PID
- Otherwise, if it has no '/' characters, treat it as a netns name
(ip-netns doesn't allow '/' in netns names)
- Otherwise, treat it as a netns path
If you want to open a persistent netns in the current directory, you can
use './netns'.
This also allows us to split the parsing of the PID|PATH|NAME option from
the actual opening of the namespaces. In turn that allows us to put the
opening of existing namespaces next to the opening of new namespaces in
pasta_start_ns. That makes the logical flow easier to follow and will
enable later cleanups.
Caveats:
- The separation of functions mean we will always generate the basename
and dirname for the netns_quit system, even when using PID namespaces.
This is pointless, since the netns_quit system doesn't work for non
persistent namespaces, but is harmless.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-08-26 06:58:37 +02:00
|
|
|
}
|
|
|
|
}
|
2021-08-12 15:42:43 +02:00
|
|
|
|
conf: Bind inbound ports with CAP_NET_BIND_SERVICE before isolate_user()
Even if CAP_NET_BIND_SERVICE is granted, we'll lose the capability in
the target user namespace as we isolate the process, which means
we're unable to bind to low ports at that point.
Bind inbound ports, and only those, before isolate_user(). Keep the
handling of outbound ports (for pasta mode only) after the setup of
the namespace, because that's where we'll bind them.
To this end, initialise the netlink socket for the init namespace
before isolate_user() as well, as we actually need to know the
addresses of the upstream interface before binding ports, in case
they're not explicitly passed by the user.
As we now call nl_sock_init() twice, checking its return code from
conf() twice looks a bit heavy: make it exit(), instead, as we
can't do much if we don't have netlink sockets.
While at it:
- move the v4_only && v6_only options check just after the first
option processing loop, as this is more strictly related to
option parsing proper
- update the man page, explaining that CAP_NET_BIND_SERVICE is
*not* the preferred way to bind ports, because passt and pasta
can be abused to allow other processes to make effective usage
of it. Add a note about the recommended sysctl instead
- simplify nl_sock_init_do() now that it's called once for each
case
Reported-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-10-13 18:21:27 +02:00
|
|
|
if (c->mode == MODE_PASTA)
|
|
|
|
nl_sock_init(c, true);
|
2021-10-11 12:01:31 +02:00
|
|
|
|
conf: Bind inbound ports with CAP_NET_BIND_SERVICE before isolate_user()
Even if CAP_NET_BIND_SERVICE is granted, we'll lose the capability in
the target user namespace as we isolate the process, which means
we're unable to bind to low ports at that point.
Bind inbound ports, and only those, before isolate_user(). Keep the
handling of outbound ports (for pasta mode only) after the setup of
the namespace, because that's where we'll bind them.
To this end, initialise the netlink socket for the init namespace
before isolate_user() as well, as we actually need to know the
addresses of the upstream interface before binding ports, in case
they're not explicitly passed by the user.
As we now call nl_sock_init() twice, checking its return code from
conf() twice looks a bit heavy: make it exit(), instead, as we
can't do much if we don't have netlink sockets.
While at it:
- move the v4_only && v6_only options check just after the first
option processing loop, as this is more strictly related to
option parsing proper
- update the man page, explaining that CAP_NET_BIND_SERVICE is
*not* the preferred way to bind ports, because passt and pasta
can be abused to allow other processes to make effective usage
of it. Add a note about the recommended sysctl instead
- simplify nl_sock_init_do() now that it's called once for each
case
Reported-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-10-13 18:21:27 +02:00
|
|
|
/* ...and outbound port options now that namespaces are set up. */
|
2022-05-01 06:36:34 +02:00
|
|
|
optind = 1;
|
|
|
|
do {
|
|
|
|
name = getopt_long(argc, argv, optstring, options, NULL);
|
|
|
|
|
2023-09-29 07:50:20 +02:00
|
|
|
if (name == 'T')
|
|
|
|
conf_ports(c, name, optarg, &c->tcp.fwd_out);
|
|
|
|
else if (name == 'U')
|
|
|
|
conf_ports(c, name, optarg, &c->udp.fwd_out.f);
|
2022-05-01 06:36:34 +02:00
|
|
|
} while (name != -1);
|
|
|
|
|
2022-07-22 07:31:17 +02:00
|
|
|
if (!c->ifi4)
|
2021-10-11 12:01:31 +02:00
|
|
|
c->no_dhcp = 1;
|
|
|
|
|
2022-07-22 07:31:17 +02:00
|
|
|
if (!c->ifi6) {
|
2021-10-11 12:01:31 +02:00
|
|
|
c->no_ndp = 1;
|
|
|
|
c->no_dhcpv6 = 1;
|
2021-09-07 11:19:57 +02:00
|
|
|
}
|
|
|
|
|
2021-10-11 12:01:31 +02:00
|
|
|
if (!c->mtu)
|
|
|
|
c->mtu = ROUND_DOWN(ETH_MAX_MTU - ETH_HLEN, sizeof(uint32_t));
|
2021-08-12 15:42:43 +02:00
|
|
|
|
|
|
|
get_dns(c);
|
|
|
|
|
2022-07-22 07:31:12 +02:00
|
|
|
if (!*c->pasta_ifn) {
|
|
|
|
if (c->ifi4)
|
|
|
|
if_indextoname(c->ifi4, c->pasta_ifn);
|
|
|
|
else
|
|
|
|
if_indextoname(c->ifi6, c->pasta_ifn);
|
|
|
|
}
|
2021-08-12 15:42:43 +02:00
|
|
|
|
2023-11-03 03:22:55 +01:00
|
|
|
if (!c->tcp.fwd_in.mode)
|
|
|
|
c->tcp.fwd_in.mode = fwd_default;
|
|
|
|
if (!c->tcp.fwd_out.mode)
|
|
|
|
c->tcp.fwd_out.mode = fwd_default;
|
|
|
|
if (!c->udp.fwd_in.f.mode)
|
|
|
|
c->udp.fwd_in.f.mode = fwd_default;
|
|
|
|
if (!c->udp.fwd_out.f.mode)
|
|
|
|
c->udp.fwd_out.f.mode = fwd_default;
|
|
|
|
|
2024-02-28 12:25:20 +01:00
|
|
|
fwd_scan_ports_init(c);
|
2021-08-12 15:42:43 +02:00
|
|
|
|
2022-02-18 00:19:10 +01:00
|
|
|
if (!c->quiet)
|
|
|
|
conf_print(c);
|
2021-08-12 15:42:43 +02:00
|
|
|
}
|