Progress Editor Temporary file

C

cbsethna

New Member
Team

Anyways we can retain the temporary file created while we open the progress editor and work in it. Currently if we exit the Editor it removes the temporary file too.

Please advise for any ideas.

[24/01/09@10:45:00.547+2300] P-006690 T-241744176 1 4GL -- Logging level set to = 4
[24/01/09@10:45:00.547+2300] P-006690 T-241744176 1 4GL -- Log entry types activated: 4GLTrace
[24/01/09@10:45:19.111+2300] P-006690 T-241744176 3 4GL 4GLTRACE Return from Main Block [/home/mfg/p02434_Untitled1.ped] STOP

Regards
Cyrus Sethna
 
Hi Rob

Thanks for your quick reply above. Seems I was not precise on my question. This is something that we do it normally. I am referring to a situation where any user who is executing the progress editor and run some query and then exits without saving . In that case this files gets deleted.

I want to preserve this file for future audit purspose.

Thanks
Cyrus Sethna
 
Procedure Editor unsaved buffers are transient by design. And even if you could get .ped files to stick around, they are files in the user's file system that they have permission to delete, so it still wouldn't fulfill any meaningful audit requirement.

So it seems your real requirement is that you want to know what query activity is happening in your database, and provide an audit trail of it?
 
Hello Rob

Yes you are correct. Want to have an audit trail of all the activities that the developers / coders and DBAs do from the progress editor may it be running queries or updating any data from the backend.

Regards
Cyrus Sethna
 
Rob
Thanks once again for a quick reply. We are using OpenEdge Release 10.2B08 . Let me know if we have other options apart from the database auditing option.

I created a script to open the Progress Editor only for mfg account and will also create a 4GL log. Now the problem is in the 4GL log i can see the .ped file getting created but cannot retain it. So now another idea is to run a small script ( sort of daemon ) on the server which will continuously check this type of file and retain it into some other folder.

Let me know if you have any other ideas.

Thanks & Regards
Cyrus Sethna
 
Stefan said:
Imagine you are able to lock down the .ped files, what are you going to when you find a .ped file with contents:

Code: 
run mindyourownbusiness.p

Fire the user and hope they did not do anything too malicious?
Click to expand...
Exactly. Or the user could run applicationstartprocedure.p, which is the name of the procedure that everyone runs, except that unbeknownst to you their copy is modified to do something different. And the modified copy can be replaced before you get a chance to check it.

It sounds like the requirements are coming from someone who doesn't really understand the platform.

The fact that you are still using a fifteen-year-old version of OpenEdge doesn't help your compliance situation and limits some of your options. It should definitely be deemed an important issue by any auditor worth their salt.

You could:
  • implement OpenEdge Auditing so you have a record of changes to any tables you care about;
  • implement a robust authentication mechanism so that your audit trail is meaningful, and lock down your database (e.g. prevent blank-user access);
  • uninstall the compiler licence to prevent session compiles of unauthorized code;
  • implement dbauthkey or package your application code in signed archive libraries (.apl) (OE 12.7+) to limit the r-code files that can be executed against your database.
Each of these steps will have limitations and operational impacts that you will need to understand, and none is a simple turnkey solution that will identify and prevent "bad guys" from doing "bad things" while allowing "good guys" to do authorized work with no impacts. For example:
  • If you remove the compiler licence, that will impact your DBAs; it limits their options with dump and load. It also may affect break-fix procedures. Do you understand what do your developers do today to implement data fixes in production?
  • If you implement OpenEdge Auditing, there are many impacts:
    • Who is going to determine your audit events and policies, and your audit data retention policy? Do they understand OE Auditing and the impact of their decisions?
    • Implementing auditing can significantly impact your system and database read and write workload.
    • Your backups will be larger and slower, and you will have a new audit archive database to maintain and secure, and you will have new processes for dumping and loading audit data, and eventually deleting it.
    • If you audit changes to everything, you are going to create massive amounts of audit data.
      • Who is the trusted auditor who will review that data, and how often, and based on what events?
      • Who will write the application that the auditor will use to review the data?
      • How will they differentiate authorized versus unauthorized data access?
  • You have to have a compiler installed somewhere. What will prevent a backup of the production database from being restored and accessed there? What will prevent a developer or dev ops tech from writing unauthorized code and compiling it there and using the .r in production?
  • If you use dbauthkey or .apl, how are you implementing key life cycle management? How will you detect key compromise or improper key use, e.g. unauthorized creation of signed code? Who watches the watchers?
  • What stops a DBA or sys admin from just bypassing the application and runtime altogether and sucking the data straight out of the database files? (Yes, that's possible when one is sufficiently informed and motivated.)
Solving these problems is hard. Defining the scope of the problems and determining which problems can be addressed in meaningful ways as opposed to implementing impotent and intrusive "security theatre" is equally hard. And to make matters worse, I can say from experience that sometimes the business decision-makers in an organization can't be bothered to learn enough about the capabilities and limitations of the OpenEdge platform and about their in-house operational procedures and application data flows to be able to reason about these problems, so they foist those tasks on the implementers with a mandate to "just fix it!" Or, as they say, "stuff runs downhill".

Good luck!
 
You must log in or register to reply here.
Back
Top