[FEATURE REQUEST] Specify config file to use via flags

[JulianGR]

Hello again!

Is your feature request related to a problem? Please describe.
A single machine from which we launch scans only has 1 user: root. However, a team of 10 people use the same root user. (I know it's not best practice...). Each time one member of the team needs to use feroxbuster, they need to change the /etc/feroxbuster/feroxbuster-config.toml file, and there is no possibility of using CONFIG_DIR/feroxbuster/ (per-user) as per documentation, since there is only root user in the machine.

Also, when using the config file in an appropiate setup (machine with multiple users, each one having a config file, plus the global one), the search for the config file that feroxbuster does is very DLL-search-Windows-like. I appreciate feroxbuster's best effort in searching for it's config file, but it becomes messy to debug which config file is being used. Wouldn't it be easier to just throw an error with the path feroxbuster is trying to use and that's it, instead of searching?

Describe the solution you'd like
It could be nice that the config file to use is specify via flags. For example:

feroxbuster -u 'https://asdf.tld' --config ./local-config.toml

Describe alternatives you've considered
N/A

Additional context
N/A

[epi052]

morning! I've seen this kind of setup in pentesting firms and similar. A workaround for yall is to use the per-target functionality, simulating per-user. As long as each user's cwd contains a config file, that one will take precendence. Additionally, if there are agreed upon defaults that most folks use, those can be placed in the more global configs.

root/
├── user-a
│   └── ferox-config.toml
├── user-b
│   └── ferox-config.toml
└── user-c
    └── ferox-config.toml

Wouldn't it be easier to just throw an error with the path feroxbuster is trying to use and that's it, instead of searching?

the whole idea of searching from top down is that the config files stack. your global config is included in the per-user config and so on down. Each 'less global' config overrides options of the same value found in 'more global' configs. A shared pentest box is exactly the environment the stacked config design is meant to serve. If your team has some agreed-upon defaults, they go in the global config. Each user can then save their preferences that deviate from the team in their own specific config. Further, each user can save off target-specific configs in whatever folder they want. As long as they cd into that target directory, the target config will apply (this is the workaround described above).

it becomes messy to debug which config file is being used

the config with the 'lowest global' level is displayed in the banner. It's also stored in the state file in the config key. It's also the first entry logged when using -o OUTFILE

[JulianGR]

Wow, didn't know about that behaviour!
Maybe the docs should reflect this in a more specific way - gonna make a pull request to the docs as soon as I have some free time.

Allright, then that solved the problem we had but anyways, wouldn't a --config flag be handy? I dont know if that would be difficult to implement, but something along the lines of:

• If there is a --config specified, override the searching behaviour
• Otherwise, search.