OWASP Amass is an information security tool that performs external network mapping and asset discovery. You can learn more about the project on GitHub, Snapcraft and Twitter.
The tool potentially accepts many input files and usually writes output files to a default output directory. It would be nice if this could be $HOME/.amass/ for future releases, and I would like to request permission to use the personal-files plug for read/write access to that directory.
OWASP Amass Project Leader
FYI, $HOME/.amass is allowed to the snap, but the snap’s runtime sets $HOME to
~/snap/amass/<revision>. Are the output files meant to be directly accessed by users or are they only accessed via the amass tool (if the later, is $HOME/.amass enough?).
That said, the amass snap is the clear owner of $HOME/.amass; it sounds like you are saying that only output files put in this directory and not, configuration, etc. Is this accurate?
The output files are meant to be directly accessed by users. The user can put a configuration file in the directory, input files containing data that determine the tool’s behavior, a log file is generated there, text and JSON files, etc.
The amass tool is the clear owner of $HOME/.amass, yet read and write access is required. Currently, the $HOME/amass directory is being used because of this constraint imposed by snap.
Is this everything you require to move forward? We appreciate your assistance.
You mentioned that the user can put configuration files in this directory. Is the configuration forward and backward compatible such that if the user also installs amass via source, traditional package manager, etc, can the snap break the other install or vice versa? As mentioned, $HOME is set to
~/snap/amass/<revision> which is meant, in part, to avoid this sort of thing.
The files are forward and backward compatible.
All of this is already taking place in ~/amass/ and we just want to change the name of the directory to ~/.amass/
Snapcraft has been preventing us from accomplishing this. I would like to make this change before Kali includes the tool in their next release without having to stop support for the Snapcraft package
+1 for use of and auto-connection for personal files where the snap.yaml uses:
@reviewers - can some of you also vote?
+1 for both from me too (ie. use and auto-connection of a dot-amass
personal files plug as specified by @jdstrand above)
Can we alter the permissions to allow for usage of the Go 1.13 os.UserConfigDir?
As indicated by the Go documentation:
On Unix systems, it returns $XDG_CONFIG_HOME as specified by the standard if non-empty, else $HOME/.config.
This would require that we have read/write permission for the following two directories:
Where does $XDG_CONFIG_HOME/amass actually resolve to inside your snap? For me that variable is blank.
+1 to personal files access to ~/.config/amass however.
For the reasons @popey outlined above, I’m on granting read/write access to
When can I assume the project has the permission?
4 votes for, 0 against for use of and auto-connect of personal-files for write access to $HOME/.amass
2 votes for and 0 against for use of and auto-connect of personal-files for write access to $HOME/.config/amass.
This is now live. Please adjust your snap to use:
The review-tools need a corresponding update that is committed but not yet in production. Once it is, it will pass automated review. In the meantime, you can request a manual review.
Is it safe to assume that we have the read access as well?
Yes, write implies read in the personal-files interface.