Is there a way to provide read access to sas data / view but mask/hide the physical path

[Aurelio]

Is it possible to create a sas table/view where the originating data path is either masked or hidden from sasuser/developer?

Scenario

Lets say we have a sas dataset LIB_A.master1 @ physical location "/sourcedata_A/master1.sas7bdat"

Lets say we have a sas dataset LIB_B.master2 @ physical location "/sourcedata_B/master2.sas7bdat"

we create a sas view of this dataset as LIBV.dsn_view_of_master1 @ physical location "/views/view_of_master1.sas7bvew"

we create an sql view of this dataset as LIBV.sql_view_of_master2 @ physical location "/views/view_of_master2.sas7bvew"

view 1:

data LIBV.dsn_view_of_master1 def/view=LIBV.dsn_view_of_master1;
   set LIB_A.master1;
run;

view2:

proc sql;

   create view LIBV.sql_view_of_master2 as

   Select * from  LIB_A.master2;

run;

So is there a way of hiding/masking the library file path of the source data?... ie the filepath of sas datasets LIB_A.master1 and LIB_B.master2?

I understand this is a little intersting... why would one want to hide the source path of the actual source data?... and views are not usually accessible if the underlying definition (source data paths are also not accessible).

However the suggestion given to me in seeking a solution to this problem is to detract/prevent the developer/sasuser from mapping directly onto the source folder path, without generating an additional copy of the source data. 

Any ideas?

thanks Aurelio

[Oligolas]

Hi, no this is not possible. A copy has to be done one way or the other or the path can be revealed. But with enough system ressources you could create a copy of the dataset in memory and delete the original path.

libname tmp "C:\Temp\source";
libname tmp1 "C:\Temp\mymemlib" memlib;

data tmp1.class;
   set tmp.class;
run;

libname tmp clear;

[Aurelio]

Thanks for suggestion...

however since I have quite some number to do this for this this is not a feasible alternative for both resources or performance in our current need.

LOGICALLY thinking it through... FAIR enough

I believe while ever a view is defined/created in SAS whether SQL or SAS dataview ... unless the base/underlying sas library, on which the view is based to source the physical data, is allocated and active when accessing the view ... then it stands to reason that the the view cannot provide an access path to that source data ... so the view fails with appropriate messages saying the source library is not available/allocated no resolvable links to the data.

I think this is fair enough as the SAS library engine is the pathway to the data on which the view was defined.

[Astounding]

Not sure if this will work, but it's worth a try ....

Create a second view that is a view of the first view.  For example:

view 1a:

data LIBV.dsn_view_of_master1a / view=LIBV.dsn_view_of_master1a;
   set LIBV.dsn_view_of_master;
run;

Give the user instructions to use LIBV.dsn_view_of_master1a

[Aurelio]

Thanks for the reply. A view of a view functions ok, so long as the source data on which the closest view to the data is still accessible and active, but fails if the source link/library to the data is not active. 

[ybolduc]

This would be a good application for SAS/Share if I understand your need properly.

With SAS/Share, you'd define the libref inside the SAS/Share server's configuration. Users would the do their libname to the SAS/Share server refering the "alias" libref instead of the actual location.

Thanks,

[Aurelio]

thanks for the suggestion.\

I think your suggestion is probably the most elegant way to achieve this... as it is really a DBMS type function we are trying to achieve. This is one of functions I believe SAS/SHARE is trying to emulate after all.  The only down side to this method is the need to licensing another product. 

I'll hang on to this this post a little longer to see what other ideas might surface before accepting the status quo ... whilst I try and test other ideas.

thanks 🙂

[s_lassen · Accepted solution]

I think it can be done using SQL, e.g.:

proc sql;
  create view libv.view_of_master1(alter=<password>)
  as select * from lib_a.master1
  using libname lib_a "/sourcedata_A";
quit;

Then the libname LIB_A is hardcoded in the view, and does not have to be allocated by the user. And in order to see the physical location by using DESCRIBE VIEW, you must know the password.

[Oligolas]

I get the path of lib_a without knowing the password, simply by editing the view with an Editor. Among all binary signs the path remains readable.

[Aurelio]

Yes I believe this solution will work on both requirements.  thanks!

1. the source data path is stored in the view ... so not requiring an additional SAS data source library to be pre-allocated.

2. the actual source data path can be masked/hidden from user... by specifying a password when creating the view, so unless the password is known the describe view will fail see sample log tested below ... if either user doesn't specify password or password is incorrectly specified the sql describe view statement will fail.

proc sql;

   create view sym.view_of_Master (alter=password)

   as select * from srce.master_table

   using libname srce "/srce_data_path";

 quit;

saslog...

25 proc sql;
26 describe view sym.view_of_Master
27 ;

25 proc sql;
26 describe view sym.view_of_Master (alter=XXXXXXX)

ERROR: Invalid or missing ALTER password on member sym.view_of_Master.
 

[Oligolas]

Hi,

as I said, open the binary file sym view with Notepad and you will see where the srce table is located in clear...
May I ask why you would like to pseudo-hide the path?

[Aurelio]

Hi Oligolas,

Thanks for your reply and continued discussion on this topic.

1. To answer your question... why hide the path to source view/data?
Firstly I believe the intention is to provide ANALYSTS with a new common "business data layer" (views of data), with a new set of "tables and columns", that may differ from original source tables, and without creating a copy of the data.
And Secondly by masking or hiding the path to the source data it would discourage/prevent "re-interpretation" of the raw data/tables through direct access to original source table/column definitions.


2. I tried viewing the physical SASView file (eg. view_of_master.sas7bvew) created with alter=password protection, with both notepad or notepad++. .... yes I admit one can see some text. Though the SQL view "create code" is not easily interpreted as it contains binary.. it is certainly visible to see a path and hence generate some hacker/interest. 

So whilst this is not Ideal to what I was after, the create SQL view with (alter=pwd) option to hide the USING ... pathname does provide another layer of "discouragement", rather than complete SOURCE table/data definition prevention ... unless better *.sas7bvew file encryption was possible.

🙂 Aurelio