Hi Nyall,
Reading through the vrt schema, I see that there's currently support
for open options for sources, but I can't see any support documented
for VSI credential options.
Has this been considered in the past?
not that I'm aware of
I'm unsure if it's an omission
by design (i.e. preventing plain text storage of credentials in a VRT)
or a feature request...
Some analysis should be done because there might *potentially* be a
security impact in doing that (besides just leaking secrets).
I'm cautious because defining general configuration options has
definitely a security impact . For example if you would allow to define
the GDAL_VRT_ENABLE_PYTHON configuration option in a VRT, that would
allow arbitrary Python code to be executed, which is a big no no, since
we want to be able to read safely untrusted VRTs, hence we can't
currently set configuration option in a VRT, and we shouldn't allow that
(or that would require restricting to a safe subset). Even allowing
setting CPL_TMPDIR could have some bad impacts, and possibly other
configuration options setting paths.
That said, on first examination of the places in the code where we call
VSIGetPathSpecificOption (only in the /vsi virtual file system) and the
type of parameter they read, and I don't think any of them would have
major security impact like arbitrary code execution. Obviously if a user
would set a secret there, it should be obvious that they must not share
their VRT.
A somewhat related functionality is the possibility to specify path
specific options in the GDAL configuration file. Cf end of paragraph of
https://gdal.org/user/configoptions.html#gdal-configuration-file . That
might help at least for personal use cases.
What kind of scenario do you have in mind? Sharing a VRT with sources
that use AWS_NO_SIGN_REQUEST=YES ?
I would say if we'd allow to set path specific option in a VRT it would
probably be prudent to restrict them to a allow-list to be on the safe
side. Although that would be a bit annoying to maintain because each
time one would introduce a new path specific option, one should extend
the allow-list with it
Even
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
