[9.x] Improve '$user' variable handling in PostgreSQL search_path #35567
+52
−1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Upon closer scrutiny of PostgreSQL CVE-2018-1058 , which I first noted in laravel/ideas#918 (comment) , a very slight tweak should be made to how the framework parses the
search_path
, as configured on the database connection.To be clear, the current implementation is not in itself vulnerable to this CVE. However, the framework does not yet fully-support the best-practice configuration described in the PostgreSQL documentation, in relation to aforementioned CVE.
It bears explaining that, in addition to literal schema names, the
search_path
accepts a special variable,$user
, that PostgreSQL resolves to the effective username. So, if thesearch_path
is defined as"$user", public
, PostgreSQL resolves that tofoouser, public
, internally, when executing queries. All of this is completely transparent to Laravel, as of #35463 (which, among other things, adds support for$user
in thesearch_path
configuration variable), with one exception, which is when querying PostgreSQL'sinformation_schema
to determine, e.g., whether a given table exists or which columns exist on a given table.This PR modifies how the
search_path
is parsed when building queries to be executed against theinformation_schema
to account for the possibility that the first schema listed in thesearch_path
is the special$user
variable.I should underscore that including this variable in the
search_path
is not some exotic use-case that nobody would ever employ; the default value in a PostgreSQL installation is"$user", public
. Granted, Laravel overrides this default with thesearch_path
value specified in the connection's configuration, but it's certainly conceivable that an end-user would want to configure Laravel to use the best-practice value, which is actually just$user
.In fact, I think consideration should be given to changing Laravel's default from
public
to$user
(inlaravel/laravel
), because the latter is safer, for the reason described in the PostgreSQL documentation (emphasis mine):With the changes in this PR, if
$user
is the first schema in thesearch_path
, thePostgresBuilder
will resolve that schema name to the username defined on the database connection whenever appropriate, e.g., in thehasTable()
andgetColumnListing()
methods.With this change in place, Laravel's
search_path
handling should now be uniform, consistent, and capable of supporting the best-practices described in the PostgreSQL documentation; specifically, configuring thesearch_path
to begin with$user
.