By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,611 Members | 2,296 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,611 IT Pros & Developers. It's quick & easy.

which udb 8.2.2 processes really need to run as root?

P: n/a
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).

Nov 12 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
_l*****@yahoo.com wrote:
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).


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"?

--
Knut Stolze
Information Integration Development
IBM Germany / University of Jena
Nov 12 '05 #2

P: n/a

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.

Nov 12 '05 #3

P: n/a
_l*****@yahoo.com wrote:
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.

Nov 12 '05 #4

P: n/a
_l*****@yahoo.com wrote:
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?

--
Knut Stolze
Information Integration Development
IBM Germany / University of Jena
Nov 12 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.