Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

root owns files in db2 instance directory.

342 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

0 new messages