Proper NTFS permissions for work directories under Windows

[ScottBass]

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;

*/

[PaulHomes · Accepted solution]

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

[ScottBass]

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

[PaulHomes]

No problem Scott. Glad I could help. I think I might bookmark this one myself.