topic Re: SAS Viya 3.5 - CAS in-memory table permissions persistence in Administration and Deployment

SAS Viya 3.5 - CAS in-memory table permissions persistence

EyalGonen — Wed, 29 Nov 2023 07:38:00 GMT

Hi experts,

I was sure that permissions set directly on an in-memory CAS table (not on the ".sashdat" file) are not persistent across table unload and re-load actions but to my surprise testing this showed that the CAS permissions were preserved across unload/load of the in-memory table. I am wondering if my testing is perhaps wrong or maybe this is the correct behavior.

For example, here is my test code:

/* load and promote table without saving it as sashdat file */

data samples.class(promote=yes);
set sashelp.class;
run;

/* set permissions directly on the in-memory table */
proc cas;
	session casauto;
	accessControl.assumeRole / adminRole="superuser"; 
	accessControl.updSomeAcsTable /
	  acs={   
		{caslib="samples",
		 table="class",
		 identity="gonen",
		 identityType="User",
		 permType="Grant",
		 permission="Select",
		 filter="name='SUB::SAS.Userid'"}};
run;quit;

/* unload table */
proc casutil; 
 droptable casdata="class" incaslib="samples" ;
run;quit;
 
/* load again and check permissions and see they are preserved */
data samples.class(promote=yes);
set sashelp.class;
run;

Re: SAS Viya 3.5 - CAS in-memory table permissions persistence

gwootton — Wed, 29 Nov 2023 19:26:03 GMT

I think you'd need to load the source table into a different caslib (cross-caslib) to trigger the name based control, otherwise CAS will set the permission on the source as well.

Creation of Name-Based Controls

In general, each table-level control that you set is tied to a source file for one of the following reasons:

- When you set the control, you specify or select a source file (for example, cars.sashdat).
- When you set the control, you specify or select an in-memory table (for example, CARS), and CAS persists the control to the corresponding source file (for example, cars.sashdat).

The exception, in which table-level controls are name-based, occurs in the following circumstances:

- You set controls on an in-memory table that has no corresponding source file.
- You set controls on an in-memory table that is disconnected from its source file (cross-caslib data).

Source: Name-Based Access Controls
https://go.documentation.sas.com/doc/en/calcdc/3.5/calauthzcas/n1bf0cwn6ae85gn1b64x2j0czu24.htm#p0ic74y2q3tobrn13d34ux1tppi3

Re: SAS Viya 3.5 - CAS in-memory table permissions persistence

EyalGonen — Thu, 07 Dec 2023 05:27:00 GMT

Hi @gwootton

Thanks for the reply! My question was about the persistence of name-based controls assigned directly to in-memory tables with no source file. I was sure these controls are volatile in the sense that they persist as long as the in-memory table is loaded to CAS and I thought that once the in-memory table was unloaded then all the name-based controls applied directly to it were lost.

In the test code I sent in my previous post, I loaded a SAS dataset directly to CAS without saving it as a "sashdat" file so there is no "source file" for this CAS in-memory table. Then I set CAS permissions directly on the in-memory CAS table, and then unloaded the table and reloaded it again from the same SAS dataset. To my surprise it seems like these CAS permissions are NOT lost when unloading the in-memory table and they persisted across the unload/load process.

So just to be sure - do name-based controls assigned directly to in-memory tables with no backing source file actually persist after unloading the associated in-memory table as my tests reveal?

Re: SAS Viya 3.5 - CAS in-memory table permissions persistence

gwootton — Thu, 07 Dec 2023 14:04:10 GMT

Hi @EyalGonen, as I understand it the name-based control is still stored, so if a table with the same name is loaded to the same caslib, the permissions would still be present. It is tied to the name though and not the data, so if you were to load the data with a different name, the controls would not apply. Similarly if you loaded different data with the same name.