Sanitize IP addresses when set using iocage
When creating a new iocage jail (using the new UI), I accidentally started the 'IPv4 Address' field with a space. The jail started up fine and did have network connectivity but I was unable to stop the jail (both via the GUI and iocage stop/restart) due to a failing ifconfig call in ioc_stop.py.
To prevent this from happening, whitespaces could be stripped when creating/adjusting the jail via the GUI (or at least warn the user).
IPv4 Address contents to reproduce issue (without quotes):
~ # iocage stop jail_name * Stopping jail_name + Running prestop OK + Stopping services OK Traceback (most recent call last): File "/usr/local/lib/python3.6/site-packages/iocage/lib/ioc_stop.py", line 241 , in __stop_jail__ stderr=su.STDOUT) File "/usr/local/lib/python3.6/site-packages/iocage/lib/ioc_common.py", line 4 51, in checkoutput out = su.check_output(*args, **kwargs) File "/usr/local/lib/python3.6/subprocess.py", line 336, in check_output **kwargs).stdout File "/usr/local/lib/python3.6/subprocess.py", line 418, in run output=stdout, stderr=stderr) subprocess.CalledProcessError: Command '['ifconfig', ' bridge0', '192.168.1.10', '-alias']' returned non-zero exit status 1. During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/local/bin/iocage", line 10, in <module> sys.exit(cli()) File "/usr/local/lib/python3.6/site-packages/click/core.py", line 722, in __ca ll__ return self.main(*args, **kwargs) File "/usr/local/lib/python3.6/site-packages/click/core.py", line 697, in main rv = self.invoke(ctx) File "/usr/local/lib/python3.6/site-packages/click/core.py", line 1066, in inv oke return _process_result(sub_ctx.command.invoke(sub_ctx)) File "/usr/local/lib/python3.6/site-packages/click/core.py", line 895, in invo ke return ctx.invoke(self.callback, **ctx.params) File "/usr/local/lib/python3.6/site-packages/click/core.py", line 535, in invo ke return callback(*args, **kwargs) File "/usr/local/lib/python3.6/site-packages/iocage/cli/stop.py", line 54, in cli ioc.IOCage(exit_on_error=True, jail=jail, rc=rc).stop() File "/usr/local/lib/python3.6/site-packages/iocage/lib/iocage.py", line 1649, in stop exit_on_error=self.exit_on_error) File "/usr/local/lib/python3.6/site-packages/iocage/lib/ioc_stop.py", line 52, in __init__ self.__stop_jail__() File "/usr/local/lib/python3.6/site-packages/iocage/lib/ioc_stop.py", line 252 , in __stop_jail__ err.output.decode("utf-8").strip())) RuntimeError: ifconfig: interface bridge0 does not exist
Adjusting the field to:
resolves the issue and allowed me to stop the jail as expected.
#1 Updated by Kris Moore over 1 year ago
- Category changed from GUI (new) to 38
- Assignee changed from Release Council to Brandon Schneider
- Priority changed from No priority to Important
- Target version set to 11.2-BETA1
Is this something you can easily sanitize on the API side? I'm thinking of the case where user drives API directly, and could have a whitespace there as well.
#2 Updated by Brandon Schneider over 1 year ago
- Status changed from Unscreened to Ready For Release
#3 Updated by Dru Lavigne about 1 year ago
- Subject changed from Unable to stop/restart iocage jail when ipv4 address starts with whitespace to Sanitize IP addresses when set using iocage
- Status changed from Ready For Release to Done
- Needs Doc changed from Yes to No
- Needs Merging changed from Yes to No
- Status changed from Ready for Testing to Passed Testing
- Severity set to New
- Needs QA changed from Yes to No
The Jail Wizard only allows a single IP address to be entered via regex validation so entering "bridge0|192.168.1.10/24" isn't possible.
Using Jail Add (Advanced Jail creation) I was able to enter ' vnet1|192.168.1.10/24' (notice preceding space) and was able to start and stop the jail without issue.
The IP/interface is invalid but this bug is not to prevent invalid input. This bug is to allow a jail with an invalid interface to be stopped. This allows the interface to be fixed.
Jail Add (Advanced Creation) is for use by more experienced people. Validating and/or preventing invalid input should be another bug.
Confirmed all of this with Brandon as well