[gdal-dev] Anyway to embed credential options into a VRT?

[Even Rouault]

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.