which udb 8.2.2 processes really need to run as root?

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

_link98@yahoo.com - 30 Aug 2005 18:49 GMT

Which of the UDB 8.2.2 ESE unix executables really need to
gain root privilege while they are running?

In my installation, the db2sysc file is owned by the instance-owner
(and relevant admin group ownership), but when the db2-instance starts
running (manually started via "su" as the instance-owner),
the db2sysc process requests root access.

I think that db2fmcd also requests root privilege.

But there may be other DB2 executables that need root level
access while they run, how do I discover what they are?

(this is on a solaris 8.2 node that runs eTrust, which logs/prevents
attempts by processes to gain root privilege, until appropriately
configured to allow it).

Reply to this Message

Knut Stolze - 30 Aug 2005 21:24 GMT

> Which of the UDB 8.2.2 ESE unix executables really need to
> gain root privilege while they are running?
[quoted text clipped - 12 lines]
> attempts by processes to gain root privilege, until appropriately
> configured to allow it).

Did you already have a look at the executables under sqllib/bin and
sqllib/adm to see which of them have the suid bit set and are owned by
"root"?

Signature

Knut Stolze
Information Integration Development
IBM Germany / University of Jena

Reply to this Message

_link98@yahoo.com - 31 Aug 2005 08:21 GMT

I looked in sqllib/bin for the instance-owner but all executables there
are owned by the instance-owner, and none have the setuid bit.

I also looked in sqllib/adm, where several executables are owned by
root and have setuid.

However, some db2 executables are not in the instance-owner's tree, but
instead are in /opt/IBM/db2 tree, and additionally some executables
that have setuid set do not appear to actually request root access at
runtime (for example: db2stop), according to eTrust. Additionally some
programs are in the administrative-server user's tree.

Hence my original question: which db2 executables actually *need* root
access at runtime (as distinct from those with setuid) ? I was hoping
for some kind of specification with an explicit list of executables
that really need root, but cannot see it in the docs yet.

Reply to this Message

Darin McBride - 31 Aug 2005 18:01 GMT

> I looked in sqllib/bin for the instance-owner but all executables there
> are owned by the instance-owner, and none have the setuid bit.

That's surprising. All executables in sqllib/bin should be owned by bin:bin
and not the instance owner.

> I also looked in sqllib/adm, where several executables are owned by
> root and have setuid.

And several executables are owned by the instance owner, or the fenced user,
and may have the setuid bit set.

> However, some db2 executables are not in the instance-owner's tree, but
> instead are in /opt/IBM/db2 tree, and additionally some executables

Don't pay attention to the man behind the curtain.

(These should not be called directly, although eTrust may not know the
difference between calling something in sqllib/bin vs /opt/IBM/db2/V8.1/bin
since sqllib/bin is not a real directory but a symlink back
to /opt/IBM/db2/V8.1/bin.)

> that have setuid set do not appear to actually request root access at
> runtime (for example: db2stop), according to eTrust. Additionally some
> programs are in the administrative-server user's tree.

Perhaps they don't need root for the cases in which you call them, but may
need root access for some other cases that you've not encountered. Off the
top of my head, I would imagine that if you upgraded to the Database
Partitioning Feature (DPF) of ESE, db2stop may need root to perform an rcmd
to all the other nodes to stop them as well. This is just a guess, and
there may be other cases that you've not run into yet.

> Hence my original question: which db2 executables actually *need* root
> access at runtime (as distinct from those with setuid) ? I was hoping
> for some kind of specification with an explicit list of executables
> that really need root, but cannot see it in the docs yet.

I would imagine that if IBM could tell you specifically which executables
*need* root, they'd just turn off root-setuid for the rest. In otherwords,
IBM would believe that the files that need root have it, and those that
don't, well, don't.

Reply to this Message

Knut Stolze - 31 Aug 2005 21:08 GMT

> However, some db2 executables are not in the instance-owner's tree, but
> instead are in /opt/IBM/db2 tree,

You can use "ls -lL" to automatically dereference links and get the
information you want. The physical placement of a file in the directory
tree hardly matters, does it?

Signature

Knut Stolze
Information Integration Development
IBM Germany / University of Jena

Reply to this Message