Tuesday, 11 November 2008

UBE security - must read!

I love problems. I'm honestly not too sure whether I like solutions as much as problems... Solutions are creative, there are many ways to solve a problem - yet the problem itself is quite 1 dimensional.

We had an issue where a report launched another report. The subsequent report stopped running... The user only had 1 role, there was no security for the user, just the role. There was no environment overrides for the user, just the one role that the user had. Security had not changed in weeks. The job stopped running...

Come on, have a think about it? Got a reason? Got a solution?

Well, as it happens the following SQL is run by the UBE:
SELECT * FROM SY812.F00926 WHERE ( AUSEQNO = 50.000000 )

This is subsequent to a bunch of other jobs, but at the end of the day this statement is run. After this statement the select on the F986101 is run, using some of the results from the previous query... Problem is that our system had a couple of roles (one old and not used before) at the same status as the real role.

This was being picked up and used in the query of security! Wow. I'm going to work out if there should be a unique index on the F00926 with AUSEQNO??

Crazy problem. I guess this means that all of the security on the server could be dodgey for this reason! I don't really want to delete all of the old roles out of this table, in case all jobs stop working because security has finally kicked in. this could happen! Remember that the web server will stop all of the one off jobs from being launched, but it's only jobs in a calling chain that would get "done in" by this.

No comments:

Extending JDE to generative AI