search

projectdiscovery / pdtm

ProjectDiscovery's Open Source Tool Manager
https://projectdiscovery.io
MIT License
674 stars 50 forks source link

Allow tools to be installed outside $HOME in /usr/local/bin/ for example #248

Closed fazlearefin closed 4 months ago

fazlearefin commented 4 months ago

Please describe your feature request:

When trying to install the extra tools (like naabu) in /usr/local/bin by specifying the option -binary-path /usr/local/bin, pdtm is complaining it is outside $HOME. I think this is not convenient for many use cases.

┌──(root㉿50b88b23b539)-[~]
└─# pdtm -binary-path /usr/local/bin -install naabu,subfinder,katana

                ____
     ____  ____/ / /_____ ___
    / __ \/ __  / __/ __ __  \
   / /_/ / /_/ / /_/ / / / / /
  / .___/\__,_/\__/_/ /_/ /_/
 /_/

                projectdiscovery.io

[INF] Current pdtm version v0.0.9 (latest)
[ERR] skipping install outside home folder: naabu
[ERR] skipping install outside home folder: subfinder
[ERR] skipping install outside home folder: katana

┌──(root㉿50b88b23b539)-[~]
└─#

Describe the use case of this feature:

Installation of the tools in /usr/local/bin will enable the tools to be used by all users of the system. This will also simplify management by keeping single copies of the tools at a global location accessible by all users.

dogancanbakir commented 4 months ago

ref: https://github.com/projectdiscovery/pdtm/pull/64

dogancanbakir commented 4 months ago

@Mzack9999 any thoughts?

Mzack9999 commented 4 months ago

@fazlearefin It was opted for a very conservative approach on Update/Write operations both for security reasons and the possibility that package managers binaries overlap with pdtm installed ones. As an example on LTS ubuntu if a pd tool binary gets replaced, the package manager is unable to perform updates as the binary hash changed. If we want to adhere to the go tools behavior, we can allow to override the behavior via environment variable (ex. $PDTM_PATH?) that would work as prefix/replacement for the default location. Anyway this shouldn't be the default behavior, and IMO not recommended.

fazlearefin commented 4 months ago

@Mzack9999 Thanks for your reply. Maybe let the user accept the risk of breaking system packages by explicitly asking the user to pass in a parameter like --break-system-packages?