which udb 8.2.2 processes really need to run as root?

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • _link98@yahoo.com

    #1

    which udb 8.2.2 processes really need to run as root?

    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).

  • Knut Stolze

    #2
    Re: which udb 8.2.2 processes really need to run as root?

    _link98@yahoo.c om wrote:
    [color=blue]
    > 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).[/color]

    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

    Comment

    • _link98@yahoo.com

      #3
      Re: which udb 8.2.2 processes really need to run as root?


      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.

      Comment

      • Darin McBride

        #4
        Re: which udb 8.2.2 processes really need to run as root?

        _link98@yahoo.c om wrote:
        [color=blue]
        > 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.[/color]

        That's surprising. All executables in sqllib/bin should be owned by bin:bin
        and not the instance owner.
        [color=blue]
        > I also looked in sqllib/adm, where several executables are owned by
        > root and have setuid.[/color]

        And several executables are owned by the instance owner, or the fenced user,
        and may have the setuid bit set.
        [color=blue]
        > However, some db2 executables are not in the instance-owner's tree, but
        > instead are in /opt/IBM/db2 tree, and additionally some executables[/color]

        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.)
        [color=blue]
        > 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.[/color]

        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.
        [color=blue]
        > 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.[/color]

        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.

        Comment

        • Knut Stolze

          #5
          Re: which udb 8.2.2 processes really need to run as root?

          _link98@yahoo.c om wrote:
          [color=blue]
          > However, some db2 executables are not in the instance-owner's tree, but
          > instead are in /opt/IBM/db2 tree,[/color]

          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

          Comment

          Working...