-
-
Notifications
You must be signed in to change notification settings - Fork 606
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
composer role adds ./vendor/bin to everbody's PATH #374
Comments
@mss thank you so much for your detailed issue! My possible solution:
Would that be enough? |
I don't know if that PATH is required later on, if not I'd go for (1) and maybe put a file somewhere which user can |
To clarify: the solution was to do 1 and 2 in sequence. So Drop the regex and declare the full path.
Yeah you are definitely right here. I have no clue how this would work if you had two different sites running on a box with two different versions of composer and such. Perhaps we should just remove this feature. I don't see it being used anywhere in the codebase. @louim why did you put this here in the first place? |
@austinpray it was done in #259 to use phpunit and al. Best solution would be to just add it to the |
Only enabling in development as a convenience method is a good compromise. So:
The only gripe would be that this might cause scripts that work on development not work on production. Is there any easy way we can warn the user if they are relying on this development-only behavior? Should we even worry about it? The person isn't supposed to be SSHing into production anyway. |
@austinpray Only thing I can think of is if the user is using composer scripts in their deployment process. |
@austinpray we also don't know if people are already using this on staging/production servers either. |
@mAAdhaTTah Composer scripts do not need the |
What about a feature flag/variable? I don't know how much backwards compatibility you need/want but the following should work:
|
@louim Oh right. In that case, I think this should probably just be development only. If that affects someone, they can move their deployment-required script into composer scripts without any loss. |
Yep so let's enable this for development only and simplify the regex to a lineinfile for |
@austinpray PRs accepted |
Fixes #374 - Remove composer vendor/bin from $PATH
This has been removed. I don't know if the slight inconvenience warrants any solution but feel free to submit a better implementation. |
Removing since it exposes a privilege escalation vulnerability. Conflicts: CHANGELOG.md
* bringing-up-to-date: Added cherry-picking notice to future-me. Added TODO commit. Replace strip_www with optional redirect to www/non-www Added TODO commit. Fix roots#353 - Allow insecure curl reqs for cron Fixes roots#374 - Remove composer vendor/bin from $PATH Added 2 TODO commits. Fix roots#436 - Let WP handle 404s for PHP files Fix roots#297 - Use `php_flag` vs `php_admin_flag` Update CHANGELOG Add wp-cli command to enable permalinks when none are set Use https://api.ipify.org for IP lookup Fix bug in Vagrantfile where VMware provider variable was encapsulated as a string Add HTTP/2 notes to README WP-CLI role improvements Fix CHANGELOG entry regarding roots#435 Add variable for whitelisted IPs Switch to mainline Nginx, replaces SPDY with HTTP2
Austin Pray asked me to file this here after I ranted on Twitter. While reviewing the Trellis playbooks (which are quite good work in general!) I noticed the following snippet in the composer role:
While I understand why this is done, adding ./vendor/bin to everybody's PATH (including root) opens the system where this role is installed on to a classic privilege escalation issue which can be exploited with a little bit of social engineering. To exploit it, first get hold of an unprivileged account. Then do something like this:
And finally send a mail to somebody you know likes to work with elevated privileges like this:
See also http://www.tldp.org/HOWTO/Path-12.html
The text was updated successfully, but these errors were encountered: