Corrupted datasets should be handled gracefully

[urosgruber]

I just spend an hour trying to figure it out why ioc list produced this

Traceback (most recent call last):
  File "/usr/local/bin/ioc", line 10, in <module>
    sys.dd:exit(cli())
  File "/usr/local/lib/python3.6/site-packages/click/core.py", line 722, in __call__
    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 invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.6/site-packages/click/core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.6/site-packages/click/core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/click/decorators.py", line 17, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/ioc_cli/destroy.py", line 101, in cli
    logger=logger
  File "/usr/local/lib/python3.6/site-packages/libioc/ListableResource.py", line 106, in __iter__
    resource = self._get_resource_from_dataset(child_dataset)
  File "/usr/local/lib/python3.6/site-packages/libioc/ListableResource.py", line 151, in _get_resource_from_dataset
    return self._create_resource_instance(dataset)
  File "/usr/local/lib/python3.6/site-packages/libioc/Jails.py", line 90, in _create_resource_instance
    **self.resource_args
  File "/usr/local/lib/python3.6/site-packages/libioc/Jail.py", line 359, in __init__
    data=self.read_config(),
  File "/usr/local/lib/python3.6/site-packages/libioc/Resource.py", line 335, in read_config
    data = self.config_handler.read()  # type: typing.Dict[str, typing.Any]
  File "/usr/local/lib/python3.6/site-packages/libioc/Jail.py", line 2127, in __getattribute__
    return object.__getattribute__(self, key)
  File "/usr/local/lib/python3.6/site-packages/libioc/Resource.py", line 341, in config_handler
    handler = object.__getattribute__(self, f"config_{self.config_type}")
  File "/usr/local/lib/python3.6/site-packages/libioc/Jail.py", line 2127, in __getattribute__
    return object.__getattribute__(self, key)
  File "/usr/local/lib/python3.6/site-packages/libioc/Resource.py", line 247, in config_type
    self._config_type = self._detect_config_type()
  File "/usr/local/lib/python3.6/site-packages/libioc/Resource.py", line 260, in _detect_config_type
    if self.config_json.exists is True:
  File "/usr/local/lib/python3.6/site-packages/libioc/Config/Prototype.py", line 124, in exists
    return os.path.isfile(self.file)
  File "/usr/local/lib/python3.6/site-packages/libioc/Config/Dataset.py", line 62, in file
    return str(os.path.join(self.dataset.mountpoint, self._file))
  File "/usr/local/lib/python3.6/posixpath.py", line 80, in join
    a = os.fspath(a)
TypeError: expected str, bytes or os.PathLike object, not NoneType

The reason for this was broken jail dataset. Steps to reproduce

zfs create sys/ioc/jails/foo
umount sys/ioc/jails/foo
ioc list

Reason for this on my end was some issue during destroy and then I needed to manually umount filesystem. It's bad that the whole tool becomes unusable and you can't do much then debug and try to find the cause.

[gronke]

libioc comes with the promise to not modify any data unless it is asked to do so. Instead of showing a stack trace, a proper warning message could notify the user about the unavailability of a jail and continue as if it would not exist at all.

Skipping over it without any message seems also okay in case of an unmounted dataset. An unmounted jail dataset seems to be a proper way to disable the jail. 🤷‍♂️

When we're not talking about the jails dataset, but the root dataset, I'm totally in for the solution to just mount it. @foo2342 does your sense for security issues trigger hearing this?