|
Problem IC63857
|
Status: Closed |
DB2SYSC'S SUPPLEMENTARY GROUPS NOT SET IF NON-INSTANCE OWNER PERFORM DB2START |
| product: |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 |
| Problem description: |
db2sysc's supplementary groups NOT set if non-instance owner
perform db2start
basin:~ # id jimyeung
uid=22388(jimyeung) gid=7777(pdxdb2)
groups=7777(pdxdb2),14(uucp),17(audio)
basin:~ # id newton
uid=1943(newton) gid=7777(pdxdb2) groups=7777(pdxdb2),200(build)
If newton (non -instance owner) runs db2start, the ruid of
db2sysc is newton, and it is changed to the instance owner
(jimyeung), group-ID=7777. BUT supplementary group IDs are
still 7777,200. Although we are changing the userId, and group
ID for db2 processes, but seems like we are forgetting about
setting the supplementary group IDs
newton@basin:/home/newton> /home/jimyeung/sqllib/adm/db2start
SQL1063N DB2START processing was successful.
newton@basin:/home/newton> ps -ef | grep jimyeung| grep db2sysc
jimyeung 7597 7595 2 21:44 pts/9 00:00:00 db2sysc
newton@basin:/home/newton> cat /proc/7597/status
Name: db2sysc
State: S (sleeping)
SleepAVG: 0%
Tgid: 7597
Pid: 7597
PPid: 7595
TracerPid: 0
Uid: 22388 22388 22388 22388 <-uid of instance owner
Gid: 7777 7777 7777 7777 <-gid of instance owner
FDSize: 64
Groups: 200 7777 <-secondary grp of newton
VmSize: 851824 kB
The instance should have the secondary groups of the instance
owner, not whatever random SYSADM happened to call db2start. |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* customer who db2start with non-instance owner *
****************************************************************
* PROBLEM DESCRIPTION: *
* db2sysc's supplementary groups NOT set if non-instance owner *
* perform db2start , therefore when access file, there will *
* be permission denied *
****************************************************************
* RECOMMENDATION: *
* db2start by instance owner *
**************************************************************** |
| Local Fix: |
Workaround:
- Ensure the instance owner start DB2.
or
- Ensure the user who starts DB2 belong to the same groups as
the instance owner. |
| available fix packs: |
DB2 Version 9.7 Fix Pack 1 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 2 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 3 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 3a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 4 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 5 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 6 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 7 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 8 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows
|
| Solution |
The instance should have the secondary groups of the instance
owner, not whatever random SYSADM happened to call db2start. |
| Workaround |
not known / see Local fix |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 20.10.2009
17.02.2010
17.02.2010 |
| Problem solved at the following versions (IBM BugInfos) |
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.7.0.1
|
 |
