RACF and SYS*AUTH tables

Mike Martin

RACF and SYS*AUTH tables
Hi all,

We are using RACF for our Db2 security (via supplied Db2 exit).

We have done very few GRANTS since we brought up Db2 5 years ago - only the GRANTS that are part of the Db2 install.

But, I am seeing lots of entries in the SYS*AUTH tables for applications.

For instance, I can see a lot of entries in our SYSPACKAGEAUTH table for application package binds for the userid that did the bind. I am wondering how/why the entries are in Db2 since we are using RACF for security?

I'm stumped how those entries got there.

We are Db2 V11 on z/OS 2.2.

Mike Martin

This email may contain confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please contact the sender and delete all copies. Any review or distribution by others is strictly prohibited. Personal emails are restricted by policy of the State Employees' Credit Union (SECU). Therefore SECU specifically disclaims any responsibility or liability for any personal information or opinions of the author expressed in this email.

Philip Sevetson

RACF and SYS*AUTH tables
(in response to Mike Martin)
Mike,

PACKAGES: When a new package is created, I believe the creator is automatically entered as authorized to bind and execute the package. You might try BINDing a package with an obvious name ("MIKETEST"?) and see what the new authorizations look like.

TABLES: When a new table is created, the table schema (CREATOR) is automatically given privileges against the table. (This doesn't work for Views.) Again, try creating a table with a strange name and look at what is in SYSTABAUTH afterwards.

Neither of these privilege grants is likely to be affected by the operations of RACF (or ACF2 or TOPSECRET).

Also, there are probably similar privileges granted to creators of other objects - databases, STOGROUPs, maybe tablespaces, sequences, etc.

--Phil Sevetson

From: MARTIN, MIKE [mailto:[login to unmask email]
Sent: Friday, September 28, 2018 12:39 PM
To: [login to unmask email]
Subject: [DB2-L] - RACF and SYS*AUTH tables

Hi all,

We are using RACF for our Db2 security (via supplied Db2 exit).

We have done very few GRANTS since we brought up Db2 5 years ago - only the GRANTS that are part of the Db2 install.

But, I am seeing lots of entries in the SYS*AUTH tables for applications.

For instance, I can see a lot of entries in our SYSPACKAGEAUTH table for application package binds for the userid that did the bind. I am wondering how/why the entries are in Db2 since we are using RACF for security?

I'm stumped how those entries got there.

We are Db2 V11 on z/OS 2.2.

Mike Martin
This email may contain confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please contact the sender and delete all copies. Any review or distribution by others is strictly prohibited. Personal emails are restricted by policy of the State Employees' Credit Union (SECU). Therefore SECU specifically disclaims any responsibility or liability for any personal information or opinions of the author expressed in this email.

-----End Original Message-----
**This e-mail, including any attachments, may be confidential, privileged, or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy, or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.**

Mike Martin

RACF and SYS*AUTH tables
(in response to Philip Sevetson)
Thanks Phil,

That is interesting.

So, if a package creator had their bind access removed from RACF, would Db2 still allow them to bind the package (since a SYSPACKAGEAUTH entry would still exist) ?

Mike Martin

From: Sevetson, Phil <[login to unmask email]>
Sent: Friday, September 28, 2018 12:45 PM
To: '[login to unmask email]' <[login to unmask email]>
Subject: [DB2-L] - RE: RACF and SYS*AUTH tables

Mike,

PACKAGES: When a new package is created, I believe the creator is automatically entered as authorized to bind and execute the package. You might try BINDing a package with an obvious name ("MIKETEST"?) and see what the new authorizations look like.

TABLES: When a new table is created, the table schema (CREATOR) is automatically given privileges against the table. (This doesn't work for Views.) Again, try creating a table with a strange name and look at what is in SYSTABAUTH afterwards.

Neither of these privilege grants is likely to be affected by the operations of RACF (or ACF2 or TOPSECRET).

Also, there are probably similar privileges granted to creators of other objects - databases, STOGROUPs, maybe tablespaces, sequences, etc.

--Phil Sevetson

From: MARTIN, MIKE [mailto:[login to unmask email]
Sent: Friday, September 28, 2018 12:39 PM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RACF and SYS*AUTH tables

Hi all,

We are using RACF for our Db2 security (via supplied Db2 exit).

We have done very few GRANTS since we brought up Db2 5 years ago - only the GRANTS that are part of the Db2 install.

But, I am seeing lots of entries in the SYS*AUTH tables for applications.

For instance, I can see a lot of entries in our SYSPACKAGEAUTH table for application package binds for the userid that did the bind. I am wondering how/why the entries are in Db2 since we are using RACF for security?

I'm stumped how those entries got there.

We are Db2 V11 on z/OS 2.2.

Mike Martin
This email may contain confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please contact the sender and delete all copies. Any review or distribution by others is strictly prohibited. Personal emails are restricted by policy of the State Employees' Credit Union (SECU). Therefore SECU specifically disclaims any responsibility or liability for any personal information or opinions of the author expressed in this email.

-----End Original Message-----
**This e-mail, including any attachments, may be confidential, privileged, or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy, or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.**
-----End Original Message-----

This email may contain confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please contact the sender and delete all copies. Any review or distribution by others is strictly prohibited. Personal emails are restricted by policy of the State Employees' Credit Union (SECU). Therefore SECU specifically disclaims any responsibility or liability for any personal information or opinions of the author expressed in this email.

Philip Sevetson

RACF and SYS*AUTH tables
(in response to Mike Martin)
Mike,

I don't think the issue arises - if you're using RACF processing in a DB2 exit, you don't get as far as the BIND statement because the exit is processed first, and refuses the ID any permission to proceed, right? Probably ought to be tested, but that's how it should work in a transparent design. The other way would introduce a semantic error.

--Phil

From: MARTIN, MIKE [mailto:[login to unmask email]
Sent: Monday, October 01, 2018 2:52 PM
To: '[login to unmask email]'
Subject: [DB2-L] - RE: RACF and SYS*AUTH tables

Thanks Phil,

That is interesting.

So, if a package creator had their bind access removed from RACF, would Db2 still allow them to bind the package (since a SYSPACKAGEAUTH entry would still exist) ?

Mike Martin

From: Sevetson, Phil <[login to unmask email]>
Sent: Friday, September 28, 2018 12:45 PM
To: '[login to unmask email]' <[login to unmask email]>
Subject: [DB2-L] - RE: RACF and SYS*AUTH tables

Mike,

PACKAGES: When a new package is created, I believe the creator is automatically entered as authorized to bind and execute the package. You might try BINDing a package with an obvious name ("MIKETEST"?) and see what the new authorizations look like.

TABLES: When a new table is created, the table schema (CREATOR) is automatically given privileges against the table. (This doesn't work for Views.) Again, try creating a table with a strange name and look at what is in SYSTABAUTH afterwards.

Neither of these privilege grants is likely to be affected by the operations of RACF (or ACF2 or TOPSECRET).

Also, there are probably similar privileges granted to creators of other objects - databases, STOGROUPs, maybe tablespaces, sequences, etc.

--Phil Sevetson

From: MARTIN, MIKE [mailto:[login to unmask email]
Sent: Friday, September 28, 2018 12:39 PM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RACF and SYS*AUTH tables

Hi all,

We are using RACF for our Db2 security (via supplied Db2 exit).

We have done very few GRANTS since we brought up Db2 5 years ago - only the GRANTS that are part of the Db2 install.

But, I am seeing lots of entries in the SYS*AUTH tables for applications.

For instance, I can see a lot of entries in our SYSPACKAGEAUTH table for application package binds for the userid that did the bind. I am wondering how/why the entries are in Db2 since we are using RACF for security?

I'm stumped how those entries got there.

We are Db2 V11 on z/OS 2.2.

Mike Martin
This email may contain confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please contact the sender and delete all copies. Any review or distribution by others is strictly prohibited. Personal emails are restricted by policy of the State Employees' Credit Union (SECU). Therefore SECU specifically disclaims any responsibility or liability for any personal information or opinions of the author expressed in this email.

-----End Original Message-----
**This e-mail, including any attachments, may be confidential, privileged, or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy, or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.**
-----End Original Message-----
This email may contain confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please contact the sender and delete all copies. Any review or distribution by others is strictly prohibited. Personal emails are restricted by policy of the State Employees' Credit Union (SECU). Therefore SECU specifically disclaims any responsibility or liability for any personal information or opinions of the author expressed in this email.

-----End Original Message-----
**This e-mail, including any attachments, may be confidential, privileged, or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy, or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.**

Mike Martin

RACF and SYS*AUTH tables
(in response to Philip Sevetson)
Makes sense. Thanks Phil! -Mike

From: Sevetson, Phil <[login to unmask email]>
Sent: Monday, October 01, 2018 3:22 PM
To: '[login to unmask email]' <[login to unmask email]>
Subject: [DB2-L] - RE: RACF and SYS*AUTH tables

Mike,

I don't think the issue arises - if you're using RACF processing in a DB2 exit, you don't get as far as the BIND statement because the exit is processed first, and refuses the ID any permission to proceed, right? Probably ought to be tested, but that's how it should work in a transparent design. The other way would introduce a semantic error.

--Phil

From: MARTIN, MIKE [mailto:[login to unmask email]
Sent: Monday, October 01, 2018 2:52 PM
To: '[login to unmask email]'
Subject: [DB2-L] - RE: RACF and SYS*AUTH tables

Thanks Phil,

That is interesting.

So, if a package creator had their bind access removed from RACF, would Db2 still allow them to bind the package (since a SYSPACKAGEAUTH entry would still exist) ?

Mike Martin

From: Sevetson, Phil <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Friday, September 28, 2018 12:45 PM
To: '[login to unmask email]' <[login to unmask email]<mailto:[login to unmask email]>>
Subject: [DB2-L] - RE: RACF and SYS*AUTH tables

Mike,

PACKAGES: When a new package is created, I believe the creator is automatically entered as authorized to bind and execute the package. You might try BINDing a package with an obvious name ("MIKETEST"?) and see what the new authorizations look like.

TABLES: When a new table is created, the table schema (CREATOR) is automatically given privileges against the table. (This doesn't work for Views.) Again, try creating a table with a strange name and look at what is in SYSTABAUTH afterwards.

Neither of these privilege grants is likely to be affected by the operations of RACF (or ACF2 or TOPSECRET).

Also, there are probably similar privileges granted to creators of other objects - databases, STOGROUPs, maybe tablespaces, sequences, etc.

--Phil Sevetson

From: MARTIN, MIKE [mailto:[login to unmask email]
Sent: Friday, September 28, 2018 12:39 PM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RACF and SYS*AUTH tables

Hi all,

We are using RACF for our Db2 security (via supplied Db2 exit).

We have done very few GRANTS since we brought up Db2 5 years ago - only the GRANTS that are part of the Db2 install.

But, I am seeing lots of entries in the SYS*AUTH tables for applications.

For instance, I can see a lot of entries in our SYSPACKAGEAUTH table for application package binds for the userid that did the bind. I am wondering how/why the entries are in Db2 since we are using RACF for security?

I'm stumped how those entries got there.

We are Db2 V11 on z/OS 2.2.

Mike Martin
This email may contain confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please contact the sender and delete all copies. Any review or distribution by others is strictly prohibited. Personal emails are restricted by policy of the State Employees' Credit Union (SECU). Therefore SECU specifically disclaims any responsibility or liability for any personal information or opinions of the author expressed in this email.

-----End Original Message-----
**This e-mail, including any attachments, may be confidential, privileged, or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy, or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.**
-----End Original Message-----
This email may contain confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please contact the sender and delete all copies. Any review or distribution by others is strictly prohibited. Personal emails are restricted by policy of the State Employees' Credit Union (SECU). Therefore SECU specifically disclaims any responsibility or liability for any personal information or opinions of the author expressed in this email.

-----End Original Message-----
**This e-mail, including any attachments, may be confidential, privileged, or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy, or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.**
-----End Original Message-----

This email may contain confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please contact the sender and delete all copies. Any review or distribution by others is strictly prohibited. Personal emails are restricted by policy of the State Employees' Credit Union (SECU). Therefore SECU specifically disclaims any responsibility or liability for any personal information or opinions of the author expressed in this email.