BookmarkSubscribeRSS Feed
araz
Fluorite | Level 6

Hello y one, 

We have a sas Base/ EG 9.3 installation in our workplace (on individual PCs ) . I need to create a centralized folder in Windows7 that keeps the log of diffrent programs run by each user. While the EG/ SAS Base should be able to write the log file in that folder , the person her/himself should not be able to delete the log file through windows. 

 

Is this possible or if there's an alternative ? Basically I neeed a write access for SAS but only read access on Windows for the purpose of audtablity.

 

is this a good practice, or there is another practice ... Share please

9 REPLIES 9
LinusH
Tourmaline | Level 20
Can't see this happen with a decentralised arcitecture. You can make this happen in a server based arcitecture, along with many other benefits.
Data never sleeps
SASKiwi
PROC Star

SAS on PCs runs under the user's Windows permissions. If you have Modify access to a shared folder for the user to add SAS logs then you can't prevent deletions.

 

It is possible to set the read-only flag on files once they have been created, but that wouldn't stop users from removing the flag and deleting the file. 

Kurt_Bremser
Super User

I achieved what you want to do by doing this:

(keep in mind that our server is UNIX-based, which is WAY above the execrable Windows)

- in each user's home directory, a logs directory is created when the user is initially added (modified system script that creates new users)

- this directory belongs to the superuser, not the created user!

- directory is rwx by the owner (superuser!), but only -w- by the group the user belongs to

- therefore the user can write new files into this directory, but can never find them or read/delete/modify them once the originating process closes

- in the SAS configuration tree for the Workspace Server, the logconfig.xml has been modified so that each Workspace Server session writes a new log file (with datetime & process number in the filename) to this directory. I also modified what is written to the log, so that we get a complete listing of all operations with exact time when they happened.

araz
Fluorite | Level 6
Hi Kurt,

Thanks for the solution. Actually our SAS ecosystem is a mixed of server and local (not necessarily) client configuration. Basically we have individual SAS installed on Windows machine , but we do run some scripts on a remote Unix machine using resubmit in our code and signon script. My understanding is that our ecosystem is not a classic client-server but yes it's a loose client server in that we access through our local SAS some resources on Unix .

Have you ever encountered such a situation ?

Many many thanks again
Kurt_Bremser
Super User

In order to make your environment more secure, you will need to do the following:

  • get rid of local SAS installations. This will also have the benefits of reducing your license and maintenance costs, as license renewals, hotfixes and upgrades need only to be done centrally.
  • Switch to Enterprise Guide or SAS Studio. SAS Studio is to be preferred if you don't need capabilities that are only present in EG at the time, as you also avoid the need to install local software.
  • this also implies that SAS/CONNECT is no longer needed. Since CONNECT starts SAS from a commandline, and the way SAS is called is kept in the local .scr file, log settings can be overridden by the local user.

Once you have done that, you can implement centrally controlled logging on the server side. As long as you run SAS locally, you leave control of logging in the hands of the individual user. Manipulating a Windows .lnk or the sasv9.cfg/autoexec.sas/XXXXX.scr files is no rocket science.

araz
Fluorite | Level 6

Totally agree with you. In my prvious company we had a client server configuration , in the snese that we had EG on our client workstations that would connnect to Server . The Sas Connect thing is new for me . On the positive side, we do have a SAS EG licences available, which is installed on our computers indivisually. I am wondering how to configure server server setting/ profile setting and ect to finally teplace the curent architecture ...

need more detailed help on this road .... being sure that current architecture is no longer acceptable from security and audit perspectives ...

any guidelines ? 

jakarman
Barite | Level 11

thinking about your options.... for a secure and tracable/auditble approach.

On linux/Unix still running with a personal account the log will be created wirh that ownership. 
Kurt, you can hide that location hoping the user will not find that location, hiding away is not securing.
The same could be doen at windows wiht Unc's and special ACL's being set.  No real difference.

 

The best security is by having users unable to do anaything. With normal advanced usages (data mining) you need sufficiënt access in a shell level. Linus, blocking xcmd is saying your are doing a LAMP approach. No SAS needed for that kind of commodity of IT.

Agree on the server approach. Are there tools in place that are doing monitoring/audting as coomon services? Why not use those.       
Having the SAS logging framwork active? Maybe there is an option.
http://support.sas.com/documentation/cdl/en/logug/67485/HTML/default/viewer.htm#p00ofr134yp6fjn1hubs...
There are a lot of appenders. system log files can get some information but are out of scope of the personal user.

Going into DBappenders  
http://support.sas.com/documentation/cdl/en/logug/67485/HTML/default/viewer.htm#p0w1cv36n6ududn1gnzz...
Sadly this doc's are telling to hard-code the user/password of the destination database.

---->-- ja karman --<-----
araz
Fluorite | Level 6
@Linosh:

Thanks for the comment. Actually our SAS ecosystem is a mixed of server and local (not necessarily) client configuration. Basically we have individual SAS installed on Windows machine , but we do run some scripts on a remote Unix machine using resubmit in our code and signon script. My understanding is that our ecosystem is not a classic client-server but yes it's a loose client server in that we access through our local SAS some resources on Unix .

Have you ever encountered such a situation ?

Many many thanks again
Add Comment
Accept as Solution
LinusH
Tourmaline | Level 20

Yes, that was (is?) quite quite common old schools client-server.

This setup usually requires that the user that is logging on to the remote server also have write permissions to create data, log files etc. I think it's hard for you to stop people to do changes to underlying files, if they really wish to. Perhaps if you really close the possibility to access local disks from any interface, and SAS/CONNECT is the only access possibility. Combine this with a NOXCMD option setting, which stops user from doing most shell calls. Obs! Untested...

 

Moving to a Intelligence Architecture gives you much better control of who can do what.

Data never sleeps

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 9 replies
  • 2466 views
  • 2 likes
  • 5 in conversation