SAS BI Dashboard can't access library

[syntheticbrain]

[Environment info - BI Dashboard 4.31 M1, SAS 9.3 M1. Linux 64-bit server. Win XP/IE7 client.]

We recently had EBI installed. While it can access, and report on, almost all of our libraries, it can't access the one library we were actually planning to use it with.

Short version: Is there any reason a base SAS library would not be available to BI Dashboard

(Very) Long version:

The library in question:

• is defined in metadata
• has read only and no file lock options set
• contains 40 tables, most of which are indexed and involved in relationships
• is readable by the BI developer account - both in metadata and physically
• contains some tables using custom formats stored in apfmtlib
• works fine in EG/DI

Attempting to create a data indicator via the table method, I get an error stating:

Unable to execute query: SQL passthru expression contained these errors: ERROR: Libname STPDATA is not assigned.

Aware that BI Dashboard has issues with libraries referencing third party RDBMS' with relationships, and that the workaround is to use an information map, we created an information map, replicated all the relationships, then tried again. And got a different error:

Error while submitting SAS code

1          options Locale=en_GB;

2          LIBNAME stpdata BASE "/data/dtf4/demandforecasting/shorttermpower/data" access=readonly filelocks=none ;

ERROR: User does not have appropriate authorization level for library STPDATA.

ERROR: Error in the LIBNAME statement.

I've since created a test library, which I've attempted to make as like the STPDATA as possible (same metadata/OS permissions, primary and foreign keys, custom formats, copied and pasted the library options in metadata). It is read fine by EBI.

What am I missing?

[jakarman]

What are we missing? a lot.....

You mentioned it is working at DI and Eguide. The programmer has access personal key.

The problem looks to be the webbased part (portal) SAS(R) BI Dashboard 4.31: User's Guide, Second Edition (Guidelines for Defining Indicator Data). You are metnioning third party RDBMS and are using information maps and seeing a base libname with a physical Unix location.

This is a mix-up of a lot. 

The DI and Eguide are running the SAS processes by using a WS-server (normally personal key)

The webservices like BI-DAshboard Portal etc. ar using a different one a Pooled-Workspace-Server or a Stored Process Server.

Often the key that is used for that is "sassrv".

The basic approach of a SAS installation is using a sassrv key that is needed to allow having access to all data on the machine for SAS usage. It is in some aspect the same way as running without system security or only using "root" "unrestricted admin".     

Get back to all requirements to the security concept. If it not that strict you could open up all data on the machine.   

[syntheticbrain]

Hi Jaap

Thanks for the response.

Apologies for the confusing reference to RDBMS. My source library is a base SAS one on the Linux server, however, when I was searching for potential reasons why it didn't work I found this http://support.sas.com/kb/40/470.html and I wondered if it might apply to SAS libraries containing relationships as well.

While if I'm honest, the reference to keys threw me slightly, it led me to retest something I thought I had already done.

The problem is down to physical/OS permissions on the files within the library. They are set to owner: SAS - rw; group: STP - rw; others - list.

The sassrv account is not a member of STP and so couldn't access the files.

My first inclination is to get sassrv added to the STP group, however I think we need to look, as you say, at the security implications of that. I think it should mean - please correct me if I'm wrong - that web users are still restricted by metadata (within which we have a similarly restricted group) and if people are acessing it physically - either via code or on the box - they need the sassrv password to do anything unless they are a member of the group themselves.

Thanks Again

Jon

[jakarman]

Jon,

Security is challenging, most of SAS is documented at bisecag. Notice the mentioned cautions. SAS(R) 9.4 Intelligence Platform: Security Administration Guide (security overview / autorization). See also the medaited access notes at SAS(R) 9.4 Intelligence Platform: Security Administration Guide (mediated access).

Web-access is mediated. This part should be secured sufficient in that way.

As soon there is a way some code (SAS language) being inserted by users, all those facilities of SAS are getting disclosed with all the access rights of the running key at OS level. You do not the password as it already running and availabe for you.

It is a same possible security hole as SQL-injection or the look alikes.

Eguide, DI, Addin-microsoft office, Eminer are intended to be used by analytics offering or even requiring that option to do code. There fore there is made a note is this document that well designed host layers is your last defence that is to be trusted..

To get it technical more compliacted for you. The sasauth module in the SAS installation is running at roor-level wiht setuid rights. It is this process that is the core to switch user-identities using SAS. It is the same logic as the SSH demon putty terminal login (being replaced by SAS). This is needing agreement wiht your security staff.

For the security setup I have a running discussion with SNLFAM1      

https://communities.sas.com/message/179331#179331