ITEM: AG0039L
How do you assign secondary group names in DB2/6000?
Question:
Customer has DB2/6000 as the Server and OS/2 Clients. The
Customer would like to assign secondary Group names in order to
define SQL permissions to the users who belong to the Group.
The Customer would like to know if the PRIMARY Authentication
Method and SECONDARY Authentication Method will be used? In
particular, will Instance, Group and Individual be used for
these authentication methods? Also, when the user connects
from the OS/2 Client to the DB2/6000 Server, how will this be
done in this environment? Should each of the users be able
to RLOGIN?
Response:
Using SMIT, select the following:
Security and Users
Users
Change/Show Characteristics of a User
Enter a User ID for User Name (eg., bud) which yields something like
the following:
Change User Attributes
Type or select values in entry fields.
Press Enter AFTER making all desired changes.
[TOP] [Entry Fields]
* User NAME bud
User ID [1112] \#
ADMINISTRATIVE User? +
LOGIN User? +
PRIMARY Group [staff] +
Group set [staff,itemsdb] +
ADMINISTRATIVE Groups [] +
SU Groups [] +
HOME Directory [/u/bud]
Initial PROGRAM [/bin/ksh]
User information [Bud Bradford]
Another user CAN SU to user? +
User CAN RLOGIN? +
Trusted path? +
Valid TTYs []
AUDIT classes []
PRIMARY authentication method []
SECONDARY authentication method []
Max FILE Size [] \#
Max CPU Time [] \#
Max DATA Segment [] \#
Max STACK Size [] \#
Max CORE File Size [] \#
Max physical MEMORY [] \#
File creation MASK []
In the field, Group set, you can add Secondary Group names. The User
ID, bud, will belong to each of the Secondary Groups selected. In the
example above, "bud" belongs to the Secondary Group "staff" and the
Secondary Group "itemsdb". Therefore, bud is granted permissions
defined for the two groups "staff" and "itemsdb". In general, a Group
ID consists of one or more Individual IDs. If an Individual ID is a
member of a Group, that Individual ID automatically has privileges
granted to the Group ID.
The fields, PRIMARY authentication method and SECONDARY authentication
method are not used here. Also, the field "User Can RLOGIN" may be
left blank because the OS/2 Clients will be using CAE/2 to connect to
the Server with DB2/6000.
DB2/6000 has a special Group ID called "PUBLIC". All users accessing a
database are automatically members of the Group PUBLIC. Granting a
privilege to PUBLIC grants that privilege to all users of a database.
DB2/6000 may consider AIX group membership when determining what
authorization a particular user has. This makes DB2/6000 group support
optional. The default is OFF - DB2/6000 will not consider AIX group
membership when determining user authorizations. In order to use the
group membership in DB2/6000, set the DB2GROUPS environment parameter to
ON before issuing the db2start command. Group support is made optional
because the AIX 'mkgroup' command, by default, can be executed by any
user. This means that any user can create a group and add users. The
DB2GROUPS=ON may be set in the user's .profile file, for example,
consider the contents of the following .profile file:
PATH=/usr/bin:/etc:/usr/sbin:/usr/ucb:$HOME/bin:/usr/bin/X11:/sbin:.
. /u/db2v1/sqllib/db2profile
DB2COMM=TCPIP
DB2GROUPS=ON
export PATH DB2COMM DB2GROUPS
if [ -s "$MAIL" ] \# This is at Shell startup. In normal
then echo "$MAILMSG" \# operation, the Shell checks
fi \# periodically.
The /etc/group file is an ASCII file which shows the following
attributes for each entry:
(1) Group Name
(2) Security Information
(3) Group Identification Number
(4) Members of the Group
Example:
system:!:0:root,mel,inst1
where Group Name = system
Security Information = !
Group Identification Number = 200
Members of the Group = root, mel, inst1
By listing the /etc/group file and finding the members which are
included in the DB2/6000 instance owner's group (sysadm1), it is
possible to tell who has the DB2/6000 sysadm privilege.
The /etc/group file should be granted read (r) access to all users and
granted write (w) access only to the root user and members of the
security group.
From an AIX command line, you can find out the Group Identification
Numbers, User ID, Primary Group and Group Sets. For example, upon
entering "id" at the AIX command line,
uid=1112(bud) gid=1(staff) groups=200(caeadm)
is presented which indicates that the User ID = bud, Primary Group
= Staff and Group Sets = caeadm. The special Group Sets "caeadm"
has been set up for DB2/6000 Client Application Enabler administration.
The Group Identification Number 1112 for user "bud" corresponds to the
entry for user "bud" in the "/etc/passwd" file. Using SMIT, the Group
Identification Numbers for "staff" and "caeadm" may be found by
selecting "List All Groups" under "Groups" under "Security and Users".
Once the Groups are defined for the various users of DB2/6000, an
authorized person can GRANT privileges. For example, in order to
Grant Table/View Privileges, you must have one of the following
authorizations:
(1) CONTROL privilege on the specified table or view
(2) SYSADM or DBADM authority
Example: GRANT SELECT ON TABLE DB2V1.ORG TO DBUSER will grant the
authority to perform an SQL SELECT command on table ORG under Instance
DB2V1 to all users (eg., bud, john, larry, mark, bill) who belong to
the DBUSER Group. The DBUSER Group will show up for all of the users
(eg., bud, john, larry, mark, bill) under Group set upon invoking SMIT
and looking at User Attributes:
Group set [staff,dbuser]
In the initial example, user "bud" has all of the privileges granted to
the groups "staff and "itemsdb". The group "staff" is an AIX group
and group "itemsdb" is a special group established for "bud" as a
DB2/6000 user to allow "bud" to use the privileges granted to all of
those individual users belonging to group "itemsdb". The privileges
granted to the users belonging to group "itemsdb" can be changed by
the one with the autority to do so. Once the change is invoked, all
users belonging to group "itemsdb" will have the new privileges.
Thus, the use of different groups by DB2/6000 provides a way to manage
the various privileges that the SYSADM, for example, wishes to give
the groups and hence, the individuals that belong to those groups.
Other command for granting privileges are covered in the DATABASE 2
AIX/6000 Command Reference manual, Publication Number SC09-1575-00.
You can use the following DB2/6000 command in order to see the the
various authorities that have been granted, groups, and tables:
db2 SELECT *\\ from SYSIBM.SYSABAUTH
Some privileges are granted automatically by DB2/6000. For example,
creating a database grants internal GRANT of DBADM to the creator and
internal GRANT of SELECT on the system catalog tables to PUBLIC (all of
whom can connect to the database).
When GRANT ADBADM is invoked, internal GRANT of CONNECT, CREATAB, and
BINDADD are implicit.
Explicit authorization is when privileges and DBADM authority are
explicitly GRANTed to users or PUBLIC by someone who holds a higher
authority or privilege (SYSADM, DBADM or CONTROL). When granting
database privileges, the name of the database is not specified because
you must first be CONNECTed to a specific database in order to execute
SQL statements. Thus, DB2/6000 knows which database you are connected
to at the time you issue a GRANT/REVOKE.
If you have SYSADM, DBADM or CONTROL authority on an object, you can
issue the following:
GRANT|REVOKE {Database Privilege | Package Privilege | Table/View
Privilege | CONTROL {ON DATABASE | ON PACKAGE | ON TABLE \ | ON INDEX \ } TO|FROM {User ID | Group ID | Public}
Support Line: How do you assign secondary group names in DB2/6000? ITEM: AG0039L
Dated: February 1995 Category: N/A
This HTML file was generated 99/06/24~13:30:28
Comments or suggestions?
Contact us