× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




On 08/04/2010, at 11:09 PM, Aaron Bartell wrote:

Basically I am in need of some insight on how best to setup locked down
environments for RPG CGI development. I need to give RPG developers enough
access to accomplish a tutorial but not allow them to touch anybody elses
stuff (i.e. jobs, libraries, spool files, etc).

Has anybody setup such an environment and would you be willing to share your
thoughts and ideas?

The usual way (i.e., education class stuff) to do this is to create a set-up program (usually in CL) that accepts a number of students and creates a library, directory, and all necessary objects for each student. Student IDs are usually pre-defined (e.g., RPGCGInnn) and all primary objects (e.g., libraries, job descriptions, etc.) are given the same name. The library and directory authority should be *PUBLIC *EXCLUDE to keep students out of other students stuff.

You would have a base library or directory of partial or template objects and this would be duplicated into the student library during the set-up process. Truly common objects that students needed to use but not change could be in a common library or directory.

Course instructions should have students create most things using the name of their student ID thus HTTPSVR(RPGCGInnn). Programs, files, etc. can have different names but must be created in their student library or directory.

If you are running this on a dedicated system/LPAR that's about all you need to do. If you have other stuff such as development occurring on the same machine then you'll want to secure other stuff from the students (you'll find at least one attempts to explore stuff outside the course).

All user libraries and directories should be *PUBLIC *EXCLUDE. Secure all STR*, END*, CRT*, DLT*, ADD*, RMV*, CHG*, etc. commands with an authorisation list that excludes the student IDs from commands they don't need. Securing the commands is somewhat extreme because if the are properly excluded from a library/directory they can't use commands on the contents anyway but I mention it only for completeness.

Create commands and CL programs to manage facilities they might need such as a way to start and end an HTTP instance. These commands would be a subset of the IBM originals and only allow managing the students own instance(s). The CL program would adopt sufficient authority to run the real secured commands. Compile with USRPRF(*OWNER) and then change the owner to something suitable.

A cleanup program blows away everything after the course is run.

This basic structure works well for standard courses but fails if you need to give students *ALLOBJ such for a security course. In that case your best bet is to use a dedicated system.


Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists

http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.