You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SqlPackage or DacFx Version: SSDT 16.0.62205.05200
.NET Framework (Windows-only) or .NET Core: 4.8 / 3.1
Environment (local platform and source/target platforms):
Windows 10
VS 2019 16.11.26
If one has an interesting folder structure with strange or fancy folder names - everyone who gets dacpac from this person will get this information thus will be able to use it, possibly against the person who produced a dacpac.
Of course, this does not look like a terrible vulnerability, but for sure this is not comfortable when you know it and is absolutely unexpected.
This behavior is reproduced in CI builds inside temp build folders which will no longer exist after the build is finished. Which makes me believe that these paths embedded into dacpac metadata are of no use.
IMO dacfx should put into the built dacpac the same (relative or whatever) path to dacpac-dependency from sqlproj as is. Otherwise this information should be removed from built dacpac to avoid described information exposure.
Steps to Reproduce:
Create a folder structure like c:/test/I like Janet/And hate Mike/dacpacs and c:/test/I like Janet/And hate Mike/new db
Put existing dacpacs into /dacpacs to use them as dependencies for new db project
Make a new sqlproj in /new db folder
Add dacpac dependencies into new db.sqlproj using relative paths to dacpacs in the ../dacpacs folder
Build this new db.sqlproj
Go into built dacpac internals, view model.xml
See absolute paths to dacpacs telling the story about your relationships with Mike and Janet to everyone
Realize that there is no place in the sources where you mentioned absolute paths describing your local workplace environment
Relative paths in the project
Become absolute paths in the dacpac after building the project
Did this occur in prior versions? If not - which version(s) did it work in?
no such version
(DacFx/SqlPackage/SSMS/Azure Data Studio)
The text was updated successfully, but these errors were encountered:
If one has an interesting folder structure with strange or fancy folder names - everyone who gets
dacpac
from this person will get this information thus will be able to use it, possibly against the person who produced adacpac
.Of course, this does not look like a terrible vulnerability, but for sure this is not comfortable when you know it and is absolutely unexpected.
This behavior is reproduced in CI builds inside temp build folders which will no longer exist after the build is finished. Which makes me believe that these paths embedded into
dacpac
metadata are of no use.IMO dacfx should put into the built dacpac the same (relative or whatever) path to dacpac-dependency from sqlproj as is. Otherwise this information should be removed from built dacpac to avoid described information exposure.
Steps to Reproduce:
c:/test/I like Janet/And hate Mike/dacpacs
andc:/test/I like Janet/And hate Mike/new db
/dacpacs
to use them as dependencies fornew db
project/new db
foldernew db.sqlproj
using relative paths to dacpacs in the../dacpacs
foldernew db.sqlproj
Relative paths in the project
Become absolute paths in the dacpac after building the project
Did this occur in prior versions? If not - which version(s) did it work in?
no such version
(DacFx/SqlPackage/SSMS/Azure Data Studio)
The text was updated successfully, but these errors were encountered: