| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
...instead of PATH. This seems to be the only change needed in
existing pasta integrations after patch:
Use explicit --netns option rather than multiplexing with PID
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
|
| |
|
|
|
|
| |
Trivial conflicts in man pages only.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When not given an existing PID or network namspace to attach to, pasta
spawns a shell. Most commands which can spawn a shell in an altered
environment can also run other commands in that same environment, which can
be useful in automation.
Allow pasta to do the same thing; it can be given an arbitrary command to
run in the network and user namespace which pasta creates. If neither a
command nor an existing PID or netns to attach to is given, continue to
spawn a default shell, as before.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When attaching to an existing namespace, pasta can take a PID or the name
or path of a network namespace as a non-option parameter. We disambiguate
based on what the parameter looks like. Make this more explicit by using
a --netns option for explicitly giving the path or name, and treating a
non-option argument always as a PID.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
[sbrivio: Fix typo in man page]
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
| |
After calling conf_ns_opt() we check for -ENOENT and print an error
message, but conf_ns_opt() prints messages for other errors itself. For
consistency move the ENOENT message into conf_ns_opt() as well.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
pasta can identify a netns as a "name", which is to say a path relative to
(usually) /run/netns, which is the place that ip(8) creates persistent
network namespaces. Alternatively a full path to a netns can be given.
The --nsrun-dir option allows the user to change the standard path where
netns names are resolved. However, there's no real point to this, if the
user wants to override the location of the netns, they can just as easily
use the full path to specify the netns.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
|
| |
|
|
|
|
|
|
|
| |
The man page states that the --userns option can be given either as a path
or as a name relative to --nsrun-dir. This is not correct: as the name
suggests --nsrun-dir is (correctly) used only for *netns* resolution, not
*userns* resolution.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both the -D (--dns) and -S (--search) options take an optional argument.
If the argument is omitted the option is disabled entirely. However,
handling the optional argument requires some ugly special case handling if
it's the last option on the command line, and has potential ambiguity with
non-option arguments used with pasta. It can also make it more confusing
to read command lines.
Simplify the logic here by replacing the non-argument versions with an
explicit "-D none" or "-S none".
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
[sbrivio: Reworked logic to exclude redundant/conflicting options]
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
The --pcap or -p option can be used with or without an argument. If given,
the argument gives the name of the file to save a packet trace to. If
omitted, we generate a default name in /tmp.
Generating the default name isn't particularly useful though, since making
a suitable name can easily be done by the caller. Remove this feature.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Fedora's parameters currently match the ones from the Makefile (which
is based on GNU recommendations), but that's not necessarily
guaranteed.
This should make the OpenSUSE Tumbleweed override for docdir
unnecessary: drop it.
Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
|
| |
|
|
|
|
|
|
| |
...as recommended in:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_requiring_base_package
Reported-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
|
| |
|
|
|
|
|
|
|
| |
...as it's used twice. The short version, however, appears hardcoded
only once in the output, and it comes straight from the rpkg macro
building the version string -- leave that macro as it is.
Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
|
| |
|
|
|
|
|
| |
...as this ends up in the actual spec file.
Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...which makes it fall under MIT licensing terms. Daniel reports that
it's very unusual for spec files to contain explicit licensing terms
and might cause minor inconveniences later on, on mass changes to
spec files.
I originally added licensing information using SPDX identifiers to
make the project fully compliant with the REUSE Specification 3.0
(https://reuse.software/spec/), but there are anyway a few more files
not including explicit licensing information. It might be worth to
fix that later on, in any case.
Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The "Simple versioning" scheme:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_simple_versioning
probably doesn't apply to passt, given that upstream git tags are
not really releases. Switch to the "Snapshots" versioning scheme:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_snapshots
Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
|
|
|
Commit a951e0b9efcb ("conf: Add --runas option, changing to given UID
and GID if started as root") dropped the call to initgroups() that
used to add supplementary groups corresponding to the user we'll
eventually run as -- we don't need those.
However, if the original user belongs to supplementary groups
(usually not the case, if started as root), we don't drop those,
now, and rpmlint says:
passt.x86_64: E: missing-call-to-setgroups-before-setuid /usr/bin/passt
passt.x86_64: E: missing-call-to-setgroups-before-setuid /usr/bin/passt.avx2
Add a call to setgroups() with an empty set, to drop any
supplementary group we might currently have, before changing GID
and UID.
Reported-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
|
