root owns files in db2 instance directory.

203 views
Skip to first unread message

Patrick Finnegan

unread,
Jun 3, 2008, 3:43:41 PM6/3/08
to

I am checking an existing DB2 installation on Red Hat Linux and I see
that root owns files in the db2 instance home directory.

Stuff like:

./sqllib/adm/db2chparm
./sqllib/adm/db2stop
./sqllib/adm/db2genp
./sqllib/adm/db2start

The instance owner can access the files because it has membership of
the owning group but I would have thought that the instance owner
would have owned all files in it's home directory. Does it matter?

Dave Hughes

unread,
Jun 4, 2008, 7:05:56 AM6/4/08
to
Patrick Finnegan wrote:

Yes, it matters. The permissions on the files in the home directory are
there for good reasons. For example, db2ckpw is a suid root executable
under ~/sqllib/security: it needs to be suid root in order to read the
shadow password file when authenticating users. Likewise, db2chpw (same
location) needs to write to the shadow password file when changing a
password.

I can't say what reasons db2start, db2stop, etc. have for being suid
root, but I'd be reasonably confident in predicting that they won't
work if changed :-).


Cheers,

Dave.

Liam Finnie

unread,
Jun 4, 2008, 8:55:57 AM6/4/08
to

One of the reasons db2start and db2stop need to be setuid-root is so
that you do not need to be the instance owner to start/stop the
instance. As long as you're a member in the SYSMAINT_GROUP (dbm
config param), you can issue the db2start/db2stop command, and the
start/stop code will verify the user is authorized to run the command,
then switch over to run as the instance-owning ID. There are also a
few other things done during db2start that require root, like setting
up ulimits, privileges, etc.

If you want to get away from setuid-root files, there's a new non-root
feature in 9.5. Using a non-root install, those files will be setuid-
instance_owner, instead of setuid-root. There are some limitations to
non-root instances though - search for 'non-root' in the 9.5
Information Center (or google 'non-root DB2') for more details.

Cheers,
Liam.

Grzegorz Powiedziuk

unread,
Sep 2, 2020, 12:50:26 PM9/2/20
to
> One of the reasons db2start and db2stop need to be setuid-root is so
> that you do not need to be the instance owner to start/stop the
> instance. As long as you're a member in the SYSMAINT_GROUP (dbm
> config param), you can issue the db2start/db2stop command, and the
> start/stop code will verify the user is authorized to run the command,
> then switch over to run as the instance-owning ID. There are also a
> few other things done during db2start that require root, like setting
> up ulimits, privileges, etc.
> If you want to get away from setuid-root files, there's a new non-root
> feature in 9.5. Using a non-root install, those files will be setuid-
> instance_owner, instead of setuid-root. There are some limitations to
> non-root instances though - search for 'non-root' in the 9.5
> Information Center (or google 'non-root DB2') for more details.
> Cheers,
> Liam.


Wow, 12 years later I find this post which answer both of my questions at the same time!
- where the heck db2sysc process is getting ~65k nofile ulimit from
(I already found that db2start has a setuid and root ownership so I was suspecting this has to be it but wasn't sure it would do it on it's own.I was about to start stracing db2start but though I would try to google this first)
- db2stop also has setuid bit and it has "execute" for anyone so I wanted to know if there are other ways db2 is making sure that user is authorized to stop the database (sysmaing_group)

thanks! Internet gives immortality ;)

Gregory

Reply all
Reply to author
Forward
0 new messages