Cleanly passing through arbitrary flags to extraction tools (e.g. -no-xattrs to sasquatch)

[mzpqnxow]

Hello. Thanks for the continued work on this tool.

Description

This is a general feature request, though I'll use a specific example to describe the potential use

I occasionally work with firmware that makes use of extended attributes (xattrs). The default behavior of sasquatch appears to be to try to preserve them while extracting:

20:39:45 › sasquatch --help 2>&1 | grep xattr
	-no[-xattrs]		don't extract xattrs in file system
	-x[attrs]		extract xattrs in file system (default)              <-- "default"
	-u[ser-xattrs]		only extract user xattrs in file system.
				Enables extracting xattrs

I would like to inhibit setting xattrs

More generally, I would like to be able to pass arbitrary command-line flags to any extraction tool

Describe the solution you'd like

It would be useful if one could influence the command-line flags that are set for extraction tools. Perhaps as some sort of opaque string passthrough (e.g. --tool-options="sasquatch:-no-xattrs") or something the developers would prefer (configuration file, environment variable are a few other options that come to mind...)

Describe alternatives you've considered

The other alternatives are:

1. Modify the code to insert the flags (either in-place, or, probably by copying the core plugins to a different directory, modifying them, and then pointing --plugins-path at that directory)
2. Use wrappers (e.g. cp /usr/bin/sasquatch /usr/bin/sasquatch.real, then have /usr/bin/sasquatch as a shell script that just does /usr/bin/sasquatch.real -no-xattrs "$@" or something)
3. Using tool-specific configuration files (I don't think this is a thing for sasquatch, though - and it's not a great generic solution since each tool would have its own convention anyway)
4. ...

Additional context

Apologies in advanced if there is a way to do this - I'm still relatively new to unblob - proficient with its use, but have rarely delved into any advanced features - a testament to how well it's designed and implemented. I'll be thankful for pointers to any documentation particularly relevant to this, in case there's already a way to do it

Thanks!

[qkaiser]

There is no way to do this right now, but the use case is legit. Passing argument through opaque strings would work best, we try to stay away from environment variables or config files.

Some open questions regarding implementation:

• should the opaque string be appended at the end of the extraction command ?
• what happens if a command line switch in the default command in unblob and the one provided by the opaque string conflicts ?
• should the opaque string overwrite all arguments, with the exception of input file / output dir ?

I would like to be able to pass arbitrary command-line flags to any extraction tool

Do you have other examples in mind, other than sasquatch and extended attributes ?

We're not exploiting extended attributes from unblob's output right now, so an easy solution would be to switch to -no[-xattrs] in the squashfs handler. We can revisit that whenever we get to work on the Detailed Metadata milestone.

[vlaci]

Another related issue that comes to my mind is related to the nix-packaging of unblob: We currently cannot properly package unblob as a python library. The issue there is that we depend on the executable wrapper providing the correct PATH to the required tools.

My idea solving that would be to configure only the extractor tool name in the handlers and there would be a config file specifying the exact command line for each tool. That config file then could be overridden, so distro packages could use different executable names and such. IMO that could solve this issue as well.

[qkaiser]

My idea solving that would be to configure only the extractor tool name in the handlers and there would be a config file specifying the exact command line for each tool. That config file then could be overridden, so distro packages could use different executable names and such. IMO that could solve this issue as well.

I like the idea, we could have people using backhand for squashfs extraction instead of sasquatch using this approach, for example.

Two questions:

• Where would we store that default configuration file ?
• The configuration file path would be provided through command line flag when using a custom one ?

[vlaci]

My idea solving that would be to configure only the extractor tool name in the handlers and there would be a config file specifying the exact command line for each tool. That config file then could be overridden, so distro packages could use different executable names and such. IMO that could solve this issue as well.

I like the idea, we could have people using backhand for squashfs extraction instead of sasquatch using this approach, for example.

Two questions:

* Where would we store that default configuration file ?

• My idea is that there would be an empty default config coming with the package.
• The current built-in defaults would be filled in using code (i.e from pydantic) when loading an empty/partial config
• Distributions can provide their own defaults when installing the package, overloading the built-ins.
• User provided configuration would be overlaid above these
• So for each command, we'd look-up user config > package config > built-in entry

* The configuration file path would be provided through command line flag when using a custom one ?

It would make sense to automatically load a user config if it is present in an XDG config directory (i.e how pyxdg does it)

[mzpqnxow]

I see that you and @vlaci already have some potential paths forward, but I'll include my reply here anyway

There is no way to do this right now, but the use case is legit. Passing argument through opaque strings would work best, we try to stay away from environment variables or config files.

Some open questions regarding implementation:

• should the opaque string be appended at the end of the extraction command ?
• what happens if a command line switch in the default command in unblob and the one provided by the opaque string conflicts ?
• should the opaque string overwrite all arguments, with the exception of input file / output dir ?

I would like to be able to pass arbitrary command-line flags to any extraction tool

Do you have other examples in mind, other than sasquatch and extended attributes ?

Previously I believe I submitted a PR to binwalk to instruct cpio to preserve timestamps - it was just an extra option to cpio. I believe unblob may already do this correctly already so it may not be a true answer to your question.

But in general, I mention it because things like preserving/not-preserving timestamps, file permissions, overriding the owner or group (or timestamps) etc. are the types of things that come to mind as potential use-cases

Essentially: no, I don't have any good specific examples with well-known use-cases

We're not exploiting extended attributes from unblob's output right now, so an easy solution would be to switch to -no[-xattrs] in the squashfs handler. We can revisit that whenever we get to work on the Detailed Metadata milestone.

That may be the wise choice. Until someone comes up with another need for this type of thing, which isn't appropriate to resolve via code change for all uses, perhaps it's best to set aside solving fully customized arguments; because without use-cases, it's hard to answer the implementation questions you mentioned above correctly.

Thanks for being open to this and thanks again for continued effort on the project