zOS, DB2 V7: BIND Authorisations for program promotion II

Michael Ebert

zOS, DB2 V7: BIND Authorisations for program promotion II
Some more thoughts: it looks like PACKADM is not good, it doesn't include
BINDADD which is required but includes EXECUTE which is not required and
in fact a security problem. So I think the binder ID needs these
authorisations:

1. BINDAGENT for all possible owners
2. BIND, COPY ON PACKAGE coll.* for all possible collections
3. CREATE IN COLLECTION *
4. BINDADD

1 and 2 would need to be adapted if the list of owners/collections changes
which is a bit tiresome but seems to be unavoidable. Any thoughts?

Dr. Michael Ebert
DB2 & Oracle Database Administrator
aMaDEUS Data Processing
Erding / Munich, Germany
----- Forwarded by Michael Ebert/MUC/AMADEUS on 23-12-05 12:20 -----





Michael Ebert/MUC/AMADEUS
23-12-05 11:25

To
DB2 Database Discussion list at IDUG <[login to unmask email]>
cc



Subject
BIND Authorisations for program promotion





Hi List,

there's a group here that is trying to replace an existing program
promotion process with a new version. I want to use this to optimize the
existing authorisations given to the userid doing the promotions.
Currently this userid is connected to RACF groups named after schemas,
which gives object ownership to the userid - far too many privileges of
course. However, I'm confused as to all the different authorisations
around the BIND process and their interaction.

The binder userid has to be able to run this command to create new
packages (they should be able to rebind, free and replace existing
packages as well):

BIND PACKAGE(pppp) OWNER(xxxx) QUALIFIER(xxxx) ....

with various values of pppp (collection name) and xxxx (owner/qualifier).
Normally a given value of xxxx has one and sometimes two pppp values: one
online (transactional) and one batch collection.
The value of ZPARM BINDNV is BINDADD.

I think the binder ID would need BINDAGENT from xxxx as well as BINDADD
and PACKADM on pppp.

Would this be a good way to give the required privileges, is there
something that they can't do, is it too much, is there a different/easier
way...? What if they needed to run the command as BIND PACKAGE(pppp)
OWNER(xxxx) QUALIFIER(yyyy) (different owner & qualifier)? Being a SYSADM,
I don't normally have to know that sort of thing so any help is
appreciated.

Dr. Michael Ebert
DB2 & Oracle Database Administrator
aMaDEUS Data Processing
Erding / Munich, Germany

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

James Campbell

Re: zOS, DB2 V7: BIND Authorisations for program promotion II
(in response to Michael Ebert)
The bindor needs BINDAGENT for whatever OWNER is used.
Usually BINDAGENT is granted to a secondary auth-id held by the
bindor.

The other privileges would be held by the BIND OWNER directly
(not via a secondary auth-id), including any table access privileges.

James Campbell

On 23 Dec 2005 at 12:27, Michael Ebert wrote:

>
>
> Some more thoughts: it looks like PACKADM is not good, it doesn't include BINDADD which is
> required but includes EXECUTE which is not required and in fact a security problem. So I think
> the binder ID needs these authorisations:
>
> 1. BINDAGENT for all possible owners
> 2. BIND, COPY ON PACKAGE coll.* for all possible collections
> 3. CREATE IN COLLECTION *
> 4. BINDADD
>
> 1 and 2 would need to be adapted if the list of owners/collections changes which is a bit tiresome
> but seems to be unavoidable. Any thoughts?
>
> Dr. Michael Ebert
> DB2 & Oracle Database Administrator
> aMaDEUS Data Processing
> Erding / Munich, Germany
> ----- Forwarded by Michael Ebert/MUC/AMADEUS on 23-12-05 12:20 -----
>
>
> Michael Ebert/MUC/AMADEUS
> 23-12-05 11:25
> To
> DB2 Database Discussion list at IDUG <DB2-
> [login to unmask email]>
>
> cc
>
>
>
>
>
> Subject
> BIND Authorisations for program promotion
>
>
>
>
>
>
>
>
>
>
> Hi List,
>
> there's a group here that is trying to replace an existing program promotion process with a new
> version. I want to use this to optimize the existing authorisations given to the userid doing the
> promotions. Currently this userid is connected to RACF groups named after schemas, which
> gives object ownership to the userid - far too many privileges of course. However, I'm confused
> as to all the different authorisations around the BIND process and their interaction.
>
> The binder userid has to be able to run this command to create new packages (they should be
> able to rebind, free and replace existing packages as well):
>
> BIND PACKAGE(pppp) OWNER(xxxx) QUALIFIER(xxxx) ....
>
> with various values of pppp (collection name) and xxxx (owner/qualifier). Normally a given value
> of xxxx has one and sometimes two pppp values: one online (transactional) and one batch
> collection.
> The value of ZPARM BINDNV is BINDADD.
>
> I think the binder ID would need BINDAGENT from xxxx as well as BINDADD and PACKADM on
> pppp.
>
> Would this be a good way to give the required privileges, is there something that they can't do, is
> it too much, is there a different/easier way...? What if they needed to run the command as BIND
> PACKAGE(pppp) OWNER(xxxx) QUALIFIER(yyyy) (different owner &qualifier)? Being a
> SYSADM, I don't normally have to know that sort of thing so any help is appreciated.
>
> Dr. Michael Ebert
> DB2 & Oracle Database Administrator
> aMaDEUS Data Processing
> Erding / Munich, Germany
> --------------------------------------------------------------------------------- Welcome to the IDUG DB2-L list.
> To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-
> l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at
> http://www.idugdb2-l.org. The IDUG List Admins can be reached at DB2-L-
> [login to unmask email] Find out the latest on IDUG conferences at
> http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Michael Ebert

Re: zOS, DB2 V7: BIND Authorisations for program promotion II
(in response to James Campbell)
The binder ID (let's call it bbbb) is a RACF group, the actual people
running the jobs will be connected to this group.

So for command BIND PACKAGE(pppp) OWNER(xxxx), you propose I issue (as
SYSADM):

0 - SET CURRENT SQLID='xxxx';
1 - GRANT BINDAGENT TO bbbb;
2 - GRANT BIND,COPY ON PACKAGE pppp.* TO xxxx;
3 - GRANT CREATE IN COLLECTION pppp TO xxxx;
4 - GRANT BINDADD TO xxxx;

This should also be possible, however I need one statement per (pppp,xxxx)
combo for 3 and 4, instead of one each in total for my solution of giving
all BIND-related privileges directly to the binder bbbb. Is there a
definite advantage of your method over mine (or a defect in mine), or is
it just a different way of skinning the cat?

Dr. Michael Ebert
DB2 & Oracle Database Administrator
aMaDEUS Data Processing
Erding / Munich, Germany








James Campbell <[login to unmask email]>
Please respond to DB2 Database Discussion list at IDUG
<[login to unmask email]>
Sent by: DB2 Data Base Discussion List <[login to unmask email]>
23-12-05 13:09

To
[login to unmask email]
cc



Subject
Re: [DB2-L] zOS, DB2 V7: BIND Authorisations for program promotion II






The bindor needs BINDAGENT for whatever OWNER is used.
Usually BINDAGENT is granted to a secondary auth-id held by the
bindor.

The other privileges would be held by the BIND OWNER directly
(not via a secondary auth-id), including any table access privileges.

James Campbell

On 23 Dec 2005 at 12:27, Michael Ebert wrote:

>
>
> Some more thoughts: it looks like PACKADM is not good, it doesn't
include BINDADD which is
> required but includes EXECUTE which is not required and in fact a
security problem. So I think
> the binder ID needs these authorisations:
>
> 1. BINDAGENT for all possible owners
> 2. BIND, COPY ON PACKAGE coll.* for all possible collections
> 3. CREATE IN COLLECTION *
> 4. BINDADD
>
> 1 and 2 would need to be adapted if the list of owners/collections
changes which is a bit tiresome
> but seems to be unavoidable. Any thoughts?
>
> ----- Forwarded by Michael Ebert/MUC/AMADEUS on 23-12-05 12:20 -----
>
> Hi List,
>
> there's a group here that is trying to replace an existing program
promotion process with a new
> version. I want to use this to optimize the existing authorisations
given to the userid doing the
> promotions. Currently this userid is connected to RACF groups named
after schemas, which
> gives object ownership to the userid - far too many privileges of
course. However, I'm confused
> as to all the different authorisations around the BIND process and their
interaction.
>
> The binder userid has to be able to run this command to create new
packages (they should be
> able to rebind, free and replace existing packages as well):
>
> BIND PACKAGE(pppp) OWNER(xxxx) QUALIFIER(xxxx) ....
>
> with various values of pppp (collection name) and xxxx
(owner/qualifier). Normally a given value
> of xxxx has one and sometimes two pppp values: one online
(transactional) and one batch
> collection.
> The value of ZPARM BINDNV is BINDADD.
>
> I think the binder ID would need BINDAGENT from xxxx as well as BINDADD
and PACKADM on
> pppp.
>
> Would this be a good way to give the required privileges, is there
something that they can't do, is
> it too much, is there a different/easier way...? What if they needed to
run the command as BIND
> PACKAGE(pppp) OWNER(xxxx) QUALIFIER(yyyy) (different owner &qualifier)?
Being a
> SYSADM, I don't normally have to know that sort of thing so any help is
appreciated.


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

James Campbell

Re: zOS, DB2 V7: BIND Authorisations for program promotion II
(in response to Michael Ebert)
You might find

(initially under your SYSADM userid)
1 - GRANT BIND,COPY ON PACKAGE pppp.* TO xxxx;
2 - GRANT CREATE IN COLLECTION pppp TO xxxx;
3 - GRANT BINDADD TO xxxx;
4 - SET CURRENT SQLID='xxxx';
5 - GRANT BINDAGENT TO bbbb;

a better order of doing things. You might also find PACKADM better than CREATE
since it will allow xxxx to overwrite a package owned by another user-id; although
this might not be a good thing. YMMV.

The advantage of using a BINDAGENT is that you also need to
GRANT SELECT, UPDATE etc ON lots-of-tables TO xxxx;
(or is xxxx the creator-id of your tables?)
If you connect your users to group xxxx, then they have these privileges (you did
write "far too many privileges of course"). If you use BINDAGENT, then the users
don't have these privileges - at least not for their own dynamic SQL.

James Campbell

On 23 Dec 2005 at 13:34, Michael Ebert wrote:

>
>
> The binder ID (let's call it bbbb) is a RACF group, the actual people running the jobs will be
> connected to this group.
>
> So for command BIND PACKAGE(pppp) OWNER(xxxx), you propose I issue (as SYSADM):
>
> 0 - SET CURRENT SQLID='xxxx';
> 1 - GRANT BINDAGENT TO bbbb;
> 2 - GRANT BIND,COPY ON PACKAGE pppp.* TO xxxx;
> 3 - GRANT CREATE IN COLLECTION pppp TO xxxx;
> 4 - GRANT BINDADD TO xxxx;
>
> This should also be possible, however I need one statement per (pppp,xxxx) combo for 3 and 4,
> instead of one each in total for my solution of giving all BIND-related privileges directly to the
> binder bbbb. Is there a definite advantage of your method over mine (or a defect in mine), or is it
> just a different way of skinning the cat?
>
> Dr. Michael Ebert
> DB2 & Oracle Database Administrator
> aMaDEUS Data Processing
> Erding / Munich, Germany
>
>
>
>
>
> James Campbell
> <[login to unmask email]>
> Please respond to DB2 Database
> Discussion list at IDUG <DB2-
> [login to unmask email]>
>
> Sent by: DB2 Data Base Discussion List
> <[login to unmask email]>
> 23-12-05 13:09
> To
> [login to unmask email]
>
> cc
>
>
>
>
>
> Subject
> Re: [DB2-L] zOS, DB2 V7: BIND Authorisations for program
> promotion II
>
>
>
>
>
>
>
>
>
>
>
> The bindor needs BINDAGENT for whatever OWNER is used.
> Usually BINDAGENT is granted to a secondary auth-id held by the
> bindor.
>
> The other privileges would be held by the BIND OWNER directly
> (not via a secondary auth-id), including any table access privileges.
>
> James Campbell
>
> On 23 Dec 2005 at 12:27, Michael Ebert wrote:
>
> >
> >
> > Some more thoughts: it looks like PACKADM is not good, it doesn't
> include BINDADD which is
> > required but includes EXECUTE which is not required and in fact a
> security problem. So I think
> > the binder ID needs these authorisations:
> >
> > 1. BINDAGENT for all possible owners
> > 2. BIND, COPY ON PACKAGE coll.* for all possible collections
> > 3. CREATE IN COLLECTION *
> > 4. BINDADD
> >
> > 1 and 2 would need to be adapted if the list of owners/collections
> changes which is a bit tiresome
> > but seems to be unavoidable. Any thoughts?
> >
> > ----- Forwarded by Michael Ebert/MUC/AMADEUS on 23-12-05 12:20 -----
> >
> > Hi List,
> >
> > there's a group here that is trying to replace an existing program
> promotion process with a new
> > version. I want to use this to optimize the existing authorisations
> given to the userid doing the
> > promotions. Currently this userid is connected to RACF groups named
> after schemas, which
> > gives object ownership to the userid - far too many privileges of
> course. However, I'm confused
> > as to all the different authorisations around the BIND process and
> their interaction.
> >
> > The binder userid has to be able to run this command to create new
> packages (they should be
> > able to rebind, free and replace existing packages as well):
> >
> > BIND PACKAGE(pppp) OWNER(xxxx) QUALIFIER(xxxx) ....
> >
> > with various values of pppp (collection name) and xxxx
> (owner/qualifier). Normally a given value
> > of xxxx has one and sometimes two pppp values: one online
> (transactional) and one batch
> > collection.
> > The value of ZPARM BINDNV is BINDADD.
> >
> > I think the binder ID would need BINDAGENT from xxxx as well as
> BINDADD and PACKADM on
> > pppp.
> >
> > Would this be a good way to give the required privileges, is there
> something that they can't do, is
> > it too much, is there a different/easier way...? What if they needed
> to run the command as BIND
> > PACKAGE(pppp) OWNER(xxxx) QUALIFIER(yyyy) (different owner
> &qualifier)? Being a
> > SYSADM, I don't normally have to know that sort of thing so any help
> is appreciated.
>

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm