topic Re: Proper NTFS permissions for work directories under Windows in Administration and Deployment

Proper NTFS permissions for work directories under Windows

ScottBass — Mon, 13 Apr 2015 23:11:36 GMT

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;

Re: Proper NTFS permissions for work directories under Windows

PaulHomes — Mon, 13 Apr 2015 23:57:14 GMT

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

Re: Proper NTFS permissions for work directories under Windows

ScottBass — Tue, 14 Apr 2015 06:05:53 GMT

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

Re: Proper NTFS permissions for work directories under Windows

PaulHomes — Thu, 16 Apr 2015 00:04:39 GMT

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