Hi, i work in a company that use an architecture SASv9 on Windows client and Sun Solaris server.
We have a lot of ETL, and DataWarehouse Table on Server.
Now we want to give SAS E.Guide to some external client, that work on Server and this user can be access only to some table.
Using the MetaData Server definition, the user is able to see only the table defined with Management console but... with EG he can submit code, for example a libname statment that by-pass the SAS metadata security.
Is possible to deny libname statment in EG?
Thank's for any suggestion, and solrry dor my bad english.
For SAS 9.1.3/EG 4.1, there is no way to limit data access from metadata. You can use OS-level file access to limit users from accessing data by removing read access rights for specific user accounts. Unfortunately this is not controllable via SAS Management Console.
Help me understand this.
What good is this whole metadata security if EG lets user issue libname statement and by-pass the security definition and get all the data that he wants and store it in his own libname/repository. Is it not false sense of security.
Message was edited by: RG at Nov 22, 2006 1:28 PM
Advanced applications like EG and Enterprise Miner allow general purpose SAS coding. As the referenced manual implies, metadata permissions are enforced by the clients, not the server (different than a relational database system.) There are many reasons why this has evolved differently, mainly because traditional SAS usage was very free form WRT where people worked and stored data. That said, applications are the enforcer of metadata permissions, NOT the SAS server.
The best way to secure your data is to use OS level permissions or give them a client like the Add-In to Microsoft Office (part of BI Server.) EG does respect MLE libname engine permissions, but someone in EG could bypass MLE with their own libname if they know where the data is on the server, unless you applied OS level dataset/directory permissions. I wish I had a better answer for you, but in SAS 9.1 there is a different paradigm than relational databases...