Hi,
Windows Server 2012 R2
SAS 9.4
Apologies if this info is already in the SAS documentation. If so please point me in the right direction.
Our server is using a common "root" for all SAS work and SAS util directories. That root is on its own disk drive. The details are F:\SASWork\Lev1 | Lev2 | Lev9\<sas work sub-dir, eg _TD<PID>_<MachineName>_
Assume that 1) our end users need X command capability from EG, and 2) some users may be working with sensitive data that only they should access.
Question: what is the best practice/correct NTFS permissions to ensure that only the "owner" of the files gets access?
I've set these NTFS permissions (which aren't correct):
F:\ Owner = MachineName\Administrators
Administrators: Full Control This folder, subfolders, and files
SYSTEM: (Same as administrators)
MachineName\Users: Read & Execute This folder, subfolders, and files (so that the SAS process can traverse the directory tree and create the sub-directory under F:\SASWork\Lev1\...)
Inheritance is turned on
F:\SASWork Owner = MachineName\Administrators
Inherits from F:\
F:\SASWork\Lev1 Owner = MachineName\Administrators
Inherits from F:\
Additional ACE: MachineName\Users Modify This folder, subfolders, and files (so that the SAS process can create the sub-directory under F:\SASWork\Lev1\...)
If the user running EG is an administrator, the SAS work sub-directory i.e. _TD12345_MachineName_ is owned by MachineName\Administrators. If the user running EG is not an administrator, the SAS work sub-directory is owned by that user. It's fine if administrators can see anyone else's data, but non-administrators should not be able to access anyone else's data.
Is there an NTFS principal I can use, such as CREATOR OWNER, such that only the owner of the SAS work directory/files can access the files, without locking down the NTFS permissions so tight that the creation of the SAS work directory itself fails?
Thanks,
Scott
P.S.: This is pretty esoteric, and I don't suspect any problems from my end users. But assuming the end user will do the right thing isn't a good premise on which to base security!
Appendix: Here is some sample code that a nefarious user could use to snoop on the work files (at least in my current environment...what about yours?)
* get pathname to work library ;
%let work=%sysfunc(pathname(work));
%put &=work;
* get all directories under the work library parent folder ;
* replace F:\SASWork\... with whatever is the parent folder for your work library ;
* note that even without XCMD the user could just guess at PIDs and use PROC COPY ;
filename dir pipe 'dir F:\SASWork\Lev1 /s /b /a:d' lrecl=1000;
data workdirs;
infile dir lrecl=1000;
length file $1000;
input;
file=_infile_;
run;
* build a program to copy their data to my work library ;
filename copy temp lrecl=1000;
data _null_;
set workdirs;
file copy lrecl=1000;
put "libname dummy '" file +(-1) "';";
put "proc copy in=dummy out=work memtype=data;";
put "run;";
put "libname dummy clear;";
run;
* check the program ;
data _null_;
infile copy lrecl=1000;
input;
put _infile_;
run;
* execute the program ;
%include copy;
* check the work library ;
proc datasets lib=work details;
quit;
/* alternative approach...runs faster but may not work 100%
* build a program to copy their data to my work library ;
filename copy "&work\copy.bat" lrecl=1000;
data _null_;
set workdirs;
file copy lrecl=1000;
put "copy " file " &work";
run;
* check the program ;
data _null_;
infile copy lrecl=1000;
input;
put _infile_;
run;
* execute the program ;
systask command "&work\copy.bat" wait;
*/
It sounds like you might be after the same sort of permission pattern as one might want for folders that house home directories (automatically created ones). i.e. where a user can create a folder which then becomes available only to them (+ admins and system).
If so, have a look at this pattern: NTFS Permissions for root share that houses Home Directories Windows Server 2008 R2 - Server Fault
It sounds like you might be after the same sort of permission pattern as one might want for folders that house home directories (automatically created ones). i.e. where a user can create a folder which then becomes available only to them (+ admins and system).
If so, have a look at this pattern: NTFS Permissions for root share that houses Home Directories Windows Server 2008 R2 - Server Fault
Thanks Paul, I've got this working thanks to the link you provided.
For those that find this thread in the future, here's what I did:
General:
F: is a dedicated drive for the work and utility files. It is the "root" of the work and util files.
We have F:\SASWork and F:\SASUtil to split out the work and utility files. These correspond to the -WORK and -UTILLOC invocation options.
We have three SAS levels on the one machine, so we have F:\SASWork\Lev1 | Lev2 | Lev9 and F:\SASUtil\Lev1 | Lev2 | Lev9.
All directories and files are owned by SYSTEM down to the directories created by SAS (i.e. _TD12345_<machinename>)
The link Paul provided uses the "Everyone" principal. I used "Users" instead of "Everyone", since all SAS users will be authenticated.
I tweaked some of the settings differently from the link Paul provided. I tested pretty heavily, and these settings appear to meet my needs. In general, I granted as little permission as possible but still work correctly. See details below.
Option 1:
F:\
SYSTEM and Administrators: Full Control ~ This folder, subfolders and files
Machinename\Users: Traverse folder / execute file + List folder / read data ~ This folder, subfolders and files (This will display as "Special permissions")
Inheritance is on
F:\SASWork
Everything is inherited
F:\SASWork\Lev1 | Lev2 | Lev9
Everything is inherited
Additional ACEs:
Machinename\Users: Traverse folder / execute file + List folder / read data + Read attributes + Create folders / append data ~ This folder only.
This allows the current SAS process to create the _TD12345_MachineName_ folder under F:\SASWork\Lev1. This directory, subfolders, and files are owned by the user who has launched the SAS process.
Note that some of these permissions duplicate permissions from the Users principal inherited from F:\.
CREATOR OWNER: Full Control ~ Subfolders and files only.
This allows the current SAS process to read/write/delete files and subfolders under _TD12345_MachineName_
Under this scenario, another user can list the contents of someone else's user library, but cannot read the data.
For example, I can execute libname foo "F:\SASWork\Lev1\_TD12345_MachineName", where that path is someone else's work folder. The DMS explorer will show the contents, i.e. SAS datasets, in that library, but I cannot open them or read their data.
In the unlikely scenario where even the name of the contents in the other user's work library is sensitive:
Option 2:
Same as above, except:
1) Turn off inheritance on Lev1 | Lev2 | Lev9
2) Remove the inherited Machinename\Users principal (i.e. remove Traverse folder / execute file + List folder / read data from This folder, subfolders, and files)
3) Propagate the explicit permissions to the child objects (i.e. SYSTEM and Administrators)
4) So, the remaining Machinename\Users principal granting Traverse folder / execute file + List folder / read data + Read attributes + Create folders / append data only applies to This folder only.
In this scenario, I cannot even list the contents of the other user's work library. libname foo "F:\SASWork\Lev1\_TD12345_MachineName", where that path is someone else's work folder, fails with Access denied.
I went with Option 1, which meets my security needs.
Thanks again for the help Paul, and I hope this may help someone else who finds this in the future.
Regards,
Scott
Message was edited by: Scott Bass: Further testing showed that CREATOR OWNER needs Full Control, not just Modify
No problem Scott. Glad I could help. I think I might bookmark this one myself.
The SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment.
Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.
Find more tutorials on the SAS Users YouTube channel.