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
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.
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.
In order to make your environment more secure, you will need to do the following:
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.
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 ?
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.
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.
The SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment.
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.