Date: Wed, 11 May 2011 11:56:21 -0400
Reply-To: Richard DeVenezia <rdevenezia@GMAIL.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Richard DeVenezia <rdevenezia@GMAIL.COM>
Subject: Re: Is this doable?
In-Reply-To: <201105111521.p4BAn8kX026128@waikiki.cc.uga.edu>
Content-Type: text/plain; charset=ISO-8859-1
Ya:
As we know SAS tables 'pass-the-buck' to the OS for certain types of
trust policies. This is in contrast to a full RDBMS that has way more
policy mechanisms (and rdbms application code overhead)
You could investigate using library concatenation along these lines:
\store\real-data
table1
...
table50
\store\restricted-data
table1 (zero rows copy)
...
table24 (absent)
table25 (absent)
table26 (absent)
...
table50 (zero rows copy)
you can use libname concatenation to perform an access suppression,
all zero row copies in restricted-data will prevent pass-through to
real-data. The tables in real-data absent in restricted-data will be
surfaced.
libname MYSTORE (restricted-data, real-data)
Instead of making zero row copies, you could also have password
protected views in restricted-data that select * from the like-named
table in real-data.
In a similar manner, you can use explicit linking to perform an access grant.
In restricted data, place symbolic links or junctions to the real-data.
The group of 5 libname is set to restricted-data.
There are a couple more possibilities, but it can get too tricky to
be manageable. Regardless, if there are trust issues, you should
really use the OS provided tools for partitioning your users accesses.
--
Richard A. DeVenezia
On Wed, May 11, 2011 at 11:21 AM, Ya Huang <ya.huang@amylin.com> wrote:
> Thanks Richard,
>
> My problem is that I can't put password on the source datasets, since the
> datasets are used by much bigger group of people, password protection
> would make it very inconvenient and unreliable (when you have a big group,
> it's going to be hard to keep the password secret :-).
>
> I'm looking for a native SAS method which can make
> this happen: A directory filled with a bunch of regular SAS datasets, let's
> say total of 50. This directory and its datasets should be accessible by
> a group of 20 people. They should be able to use the datasets as any other
> datasets. Even with the old SAS system viewer, they should be able to
> open the datasets without having to type in a password. Among the 50, there
> are 3 datasets and only the 3 should be accessible by a different group of
> people, let's say 5 of them. These 5 should only be able to open the 3
> dataset, password or not. They may 'see' the other 47 datasets, but they
> should not be able to open/read those datasets. The reason I want to set
> up this way is that the 50 datasets may get constantly updated, the small
> group of people who use the 3 dataset therefore can get the latest updated.
>
> OS level access control if not an option at this moment, since it has to
> be done by our IT, who is really reluctant.
>
> Thanks
>
> Ya
>
> On Wed, 11 May 2011 09:48:34 -0400, Richard DeVenezia
> <rdevenezia@GMAIL.COM> wrote:
>
>>On Fri, May 6, 2011 at 1:03 PM, Ya Huang <ya.huang@amylin.com> wrote:
>>> Hi there,
>>>
>>> Suppose I create a permanent view and save it in one folder. The view
>>> is pointing to a dataset in another folder, which some people do not
>>> have access. What would happen if I give those people the access
>>> to the view? Can they now access the underline dataset via the view?
>>> I guess not, because they have to define the libname for both the
>>> view folder and dataset folder. What about embed the path in the view?
>>>
>>> My intention is to find a way that give certain people access to
>>> certain datasets in a folder, but not all the datasets in there.
>>
>>Ya:
>>
>>A native SAS approach would be to place a SAS password on the source
>>datasets and incorporate those passwords in the view source. If a
>>view contains a password it will appears as XXXXX when the view source
>>is examined (via DESCRIBE, etc)
>>
>>For granularity at the user account level, one approach is to use the
>>operating system ACL features to grant or deny read and write
>>privileges to user group or user id.
>>
>>You can access the source tables via unc or mapped drive, for example
>> SET '\\server\share\path\table_name'; or
>> SET 'X:\dataplace\projectx\table_name'
>>
>>--
>>Richard A. DeVenezia
>>http://www.devenezia.com
>
| 
