The hosts order might have some importance for the caller, so don't
attempt to sort them. Also don't try to dedupe them, it might be
for some reason that the same host appears twice in the list,
so don't make any assumptions on how we are used and just apply
the command on the given hosts, exactly in the order given.
To avoid confusion, we now use 'subnet' to talk about a subnet
represented with the CIDR notation, such as 10.0.0.0/8.
In in that case:
- 10.0.0.0/8 is a 'subnet'
- 10.0.0.0 is the 'prefix'
- 8 is the 'prefix length', or by extension the 'subnet length'
Use these words everywhere in the code and documentation for clarity.
As ping can return unknown exit codes for unknown cases,
just never bail out to avoid taking bad decisions,
as we retry each second maximum, there's no DoS risk
Under some specific conditions, the execute() call could get deadlocked with the program it started,
both waiting for each other to read or write data. This is easier to reproduce with the `scp` plugin,
where the transfer would just stall. Introduce an additional intermediate buffer to avoid this race condition.
This CVE will not be fixed by scp authors, and as far as The Bastion
is concerned, this can't be achieved by anybody that doesn't already
have shell access to the remote server in addition to the scp rights,
but let's still block it for good measure.
Commit that introduced the performance degradation is effab4a
(fix: workaround for undocumented caching in getpw/getgr funcs)
Rewrote caching at the getpwent/getpwnam/getgrent/getgrnam level,
which restores performance pre-effab4a and even enhances it in somes cases,
for example on a 2000-accounts and 2000-groups bastion, we are:
- 11% faster on --osh help
- 35% faster on --osh selfListAccesses (reduces syscalls by 87%)