Date:         Wed, 28 Jul 2010 12:24:07 -0400
Reply-To:     Suzanne McCoy <Suzanne.McCoy@CATALINAMARKETING.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Suzanne McCoy <Suzanne.McCoy@CATALINAMARKETING.COM>
Subject:      Re: data(read=)
Comments: To: "Carlin, Justin M." <Carlin.Justin@mayo.edu>
In-Reply-To:  <7467DB4C3DB40F499B9ACE714BB1B3AB038D2C36@msgebe15.mfad.mfroot.org>
Content-Type: text/plain; charset="us-ascii"

I wonder if you could build a permanent view that contains the password and hide the code that builds the view in a compiled catalog entry.

-----Original Message-----
From: Carlin, Justin M. [mailto:Carlin.Justin@mayo.edu]
Sent: Thursday, July 22, 2010 2:19 PM
To: Suzanne McCoy; SAS-L@LISTSERV.UGA.EDU
Subject: RE: Re: data(read=)

This has really been the problem all along. I have a permanent dataset
that is read multiple times during this matching macro that needs to be
open to change for differing matching techniques. However the dataset
contains sensitive information that needs to be locked down. But the
list of individual users change on a daily basis. The number of users is
70+ so tradition OS group permissions becomes problematic.

We have a complied macro that handles assigning libnames for Sybase
tables after determining if a user is allowed. However I haven't found a
way to do this with just a sas dataset. We did have this as a Sybase
table, but going between platforms took too long.

I thought data(read=) would be a good option, but I don't like the idea
of a password floating around for the well versed programmer to find.
The lazy solution has always been to put a global macro variable in the
complied macro and set it to the password if they have access and to
garbage if they don't. However with this approach, there are a dozen
ways to get the password if you have access and then they don't need the
complied macro.

I will take any solution to this problem but a complete solution has to
allow for:

1. users to see the matching algorithm which has the dataset in it.
2. User ability to change options mprint mlogic symoblen, because if #1
is possible they will.
    Option nomprint nomlogic nosymbolen;
    data a(read=&pass)
Above won't work as the user has the option to comment the option line
out, or %put &pass
3. Has to be secure
   macro pw();
      %local pass;
      %let pass=the actual password;
      &pass;     or symget(pass);  or resolve(pass);
   mend;
   data a(read=%pw)
Doesn't work because the password is easily seen by a call to %pw
   data a(read=resolve(pass))
Doesn't work because SAS errors when it encounters the (pass). It
doesn't resolve it before executing the read statement. And again there
is nothing preventing the user from %put &pass;



-----Original Message-----
From: Suzanne McCoy [mailto:Suzanne.McCoy@catalinamarketing.com]
Sent: Thursday, July 22, 2010 11:48 AM
To: Carlin, Justin M.; SAS-L@LISTSERV.UGA.EDU
Subject: RE: Re: data(read=)

Then you might take the approach of storing the password in a file
(protect with OS security).  The program can then read that file to
create a macro variable that can be used as the read password.  Be sure
to turn off the symbolgen option so that it doesn't print the macro
variable value to the log.

-----Original Message-----
From: Carlin, Justin M. [mailto:Carlin.Justin@mayo.edu]
Sent: Wednesday, July 21, 2010 4:51 PM
To: Suzanne McCoy; SAS-L@LISTSERV.UGA.EDU
Subject: RE: Re: data(read=)


 Proc pwencode has only one note in the documentation and that is it
doesn't work for data set read option. Actually a side note, the read=
options treats everything as a password so when it hits a (, { or other
invalid sas name character it fails.
Justin

-----Original Message-----
From: Suzanne McCoy [mailto:suzanne.mccoy@CATALINAMARKETING.COM]
Sent: Wednesday, July 21, 2010 3:48 PM
To: SAS-L@LISTSERV.UGA.EDU; Carlin, Justin M.
Subject: Re: data(read=)

Try using the encrypted version created via proc pwencode;