Where and what objects to look for to review program changes - directory and file permissions in Unix

[quote]
Posted By lidersuper on 07/06/2010 02:35 PM
I am auditing IT general controls for a Lawson GL application. I have normally looked at PD, WS, SCR, RPT, and PGM file extensions under the PROD and SYSTEM Unix diretories to review the population of program changes during a fiscal year.

1. Should I also be looking at other file extensions (.xml, .gnt ..) and other directories to identify production objects that have been modified and that could change the way the application performs calculations or reports?

-- YES you should be looking at the other file extensions, especially .js, .htm in the web code folder and subfolders. Also look at .cfg, .properties, etc.

2. Most of the files in the system I am reviewing have read-only permissions set. However most of the directories have rwx permissions set at the group and 'world' level. Users could replace production objects (delete old object and create new modified object).. can the application continue to work with these new objects without a new compilation? or would the new objects need to me compiled along with the rest of objects in order to work?

-- If you're talking about COBOL, new objects (PD,WS,SCR,RPT) must be recompiled together for any new executible object to be create. You can't just replace the PD,WS,SCR,RPT and NOT recompile and expect a new executible object to be created.

3. The system administrator says that he/she is using the permsmaint tool after each CPT to make sure directory and file permission settings are all restored back to the original / safe setting. Is permsmaint a utility that can be easily modified to set different permissions at the directory and file level.

-- Permissions to run permsmaint should be that only for sys admin level. There are control files that are used in conjunction with it which can be edited to specific the specific folders and permissions you want to set.

4. Are program change developers required any specific access to the production environment, or can they perform changes in a separate environment and then turn them in to the administrator for implementation / compilation in the production environment?

-- It depends on your organization. Usually the case is that developers develop in a development environment, and promotion to a QA or production environment is done by someone else, many times it's the sys admin. Also (it depends on your organization), it may be that developers are locked out of PROD to do code changes and recompiles. This is something that you may want, but again it depends on your organization's policies. You may in fact want some type of ability to make program changes/compiles in PROD in case of critical issues that must be resolved.

-Roger

Thanks!
[/quote]