Your SAS programs, embedded in web apps and elsewhere

setting OS permissions for SASSRV account

Accepted Solution Solved
Reply
PROC Star
Posts: 1,322
Accepted Solution

setting OS permissions for SASSRV account

Hi,

I'm just starting to learn about BI solutions and stored processes, and have a basic permissions/security question.  (I know more about SAS than I do about linux, so I may not phrase this correctly).

As I understand it, if a user runs a stored process that runs on the stored process server, they authenticate to the server as SASSRV.

So if I write a stored process that will read in SAS datasets sitting on the server in /users/Quentin/projData,  I need to give SASSRV access to /users/Quentin/projData  (again at the OS level, not the metadata level).

If I give SASSRV access to the data, then I'm deciding to control access to the data through the SAS metadata server.  Fair enough.  So I register the library and data in the metadata and lock down access to only me and my boss who will be running the stored process.

Suppose Joe down the hall gets curious about the data in /Users/Quentin.

If he tries to access it directly, the OS won't let him (because JOE doesn't have the permissions).

If he tried to access the data via:

  libname mylib meta library="Quentin data";

the metadata won't let him.

But if he writes a stored procedure that accesses the data with a native libname:

  libname mylib library="/users/Quentin/projData";

then he by-passes the meta-data, so he would be able to get to the data (because when he runs the stored process, he will authenticate as SASSRV, not JOE.

Am I understanding this correctly?

(I noticed a few places in the docs where I think it described this sort of scenario.  And at one point I think it even said if you had super-secret data you might create a separate SAS server for those users.  So everyone in HR might log into an HR server, which would then authenticate them as SASSRVHR to the OS, allowing more OS-level control.)

Thanks,

-Q.


Accepted Solutions
Solution
‎04-27-2012 02:12 PM
Regular Contributor
Posts: 155

Re: setting OS permissions for SASSRV account

Quentin,

In answer to (what I think) are your two quesitons.

First, the Stored Process Server is an up and running server (think of a daemon) that accepts requests. That SAS server is started using the sassrv userid (which needs to be a define user id at the OS level). So, yes, the sassrv id needs whatever rights that any stored processes will need. So it will need read access to the OS folder. And if your stored processes will write data to a location, the sassrv account will need write access at the OS level.

Next, the user who requests to run a stored process, does not authenticate to the server using sassrv. But they do need to be defined in the sas metadata (i.e., have a userid which need not be an OS level id) and they must have read access to the metadata for the stored process(es) they want to run. The default is typically that users have read access.

So yes, you will have to give the sassrv account access to /users/Quentin/projData (plus whereever your stored process code is).

Next, WRT the meta libname engine, you are correct about the permissions. And likewise if Joe (down the hall) knows where the library is and hard-codes a libname to that path, yes he can access the data. That assumes of course, that Joe has access to save stored processes, . . . . .

While at SGF I was speaking to some SAS developers and in 9.3M2 (due around the August timeframe), there is going to be a facility to bind the metadata security to the OS security that will prevent Joe from issuing his own libname to that folder. I am not sure of all the details, but it does restrict access whenever the SAS session is connected to the metadata server (e.g., using the Stored Process Server). It will not prevent such access if Joe logs onto the server and starts his own SAS session and does not define the metadata server.

And note that all of the above relates to the Stored Process Server. The rules are slightly different when a Workspace Server (WS) is used (e.g., in WRS, AMO, EG and for stored processes where the WS is defined in the metadata as the target server for a stored process.

HTH,

donh

View solution in original post


All Replies
Solution
‎04-27-2012 02:12 PM
Regular Contributor
Posts: 155

Re: setting OS permissions for SASSRV account

Quentin,

In answer to (what I think) are your two quesitons.

First, the Stored Process Server is an up and running server (think of a daemon) that accepts requests. That SAS server is started using the sassrv userid (which needs to be a define user id at the OS level). So, yes, the sassrv id needs whatever rights that any stored processes will need. So it will need read access to the OS folder. And if your stored processes will write data to a location, the sassrv account will need write access at the OS level.

Next, the user who requests to run a stored process, does not authenticate to the server using sassrv. But they do need to be defined in the sas metadata (i.e., have a userid which need not be an OS level id) and they must have read access to the metadata for the stored process(es) they want to run. The default is typically that users have read access.

So yes, you will have to give the sassrv account access to /users/Quentin/projData (plus whereever your stored process code is).

Next, WRT the meta libname engine, you are correct about the permissions. And likewise if Joe (down the hall) knows where the library is and hard-codes a libname to that path, yes he can access the data. That assumes of course, that Joe has access to save stored processes, . . . . .

While at SGF I was speaking to some SAS developers and in 9.3M2 (due around the August timeframe), there is going to be a facility to bind the metadata security to the OS security that will prevent Joe from issuing his own libname to that folder. I am not sure of all the details, but it does restrict access whenever the SAS session is connected to the metadata server (e.g., using the Stored Process Server). It will not prevent such access if Joe logs onto the server and starts his own SAS session and does not define the metadata server.

And note that all of the above relates to the Stored Process Server. The rules are slightly different when a Workspace Server (WS) is used (e.g., in WRS, AMO, EG and for stored processes where the WS is defined in the metadata as the target server for a stored process.

HTH,

donh

PROC Star
Posts: 1,322

Re: setting OS permissions for SASSRV account

Thanks very much Don, that makes sense.

I feel like I've been reading documentation and SGF papers for days.  And in the docs, several times I ran across the statement

"Caution: Some clients enable power users to create and run SAS prgorams that access data directly, bypassing metadata-layer controls....It is essential to manage physical layer access..."

So wanted to make sure I understood how this might happen.  At least with the stored process server, it seems odd that I need to relax the operating system permissions to get things to work.  And in so doing, open up a little bit of a hole.

That is, I've been places where people felt good about saying that only the SAS programmers working on a project could see the project's data.  And it was all just done with *NIX groups.  So if we open directories up SASSRV, we can't really say that anymore.  Because whether malicious or just by accident, a SAS programmer could write a stored process which points directly to a directory (forgetting to use the META engine), and then look at, even update data.

As I understand it, the workspace server authenticates to the OS as the specific user (not a generic SASSRV account).  It's a shame the stored procedure server isn't the same.  But of course if it was, then I would be complaining about having to set up *NIX accounts for everyone who wants to run one of my stored procedures. : )

I think I saw a blog post a few weeks ago, where someone from SAS was saying that they had seen places where people were so scared of folks using libname statements to bypass security, they went to the point of making an old-style (command?) macro named libname, so that when you wrote a libname statement, it would execute a macro which returned to the log "LIBNAME statement not allowed".  And the poster's point was that was silly, and that they shouldn't be worried as long as they had their OS-level permissions right.  Wish I could find a link..

Thanks again,

--Q.


🔒 This topic is solved and locked.

Need further help from the community? Please ask a new question.

Discussion stats
  • 2 replies
  • 1399 views
  • 0 likes
  • 2 in conversation