Loading ...
Sorry, an error occurred while loading the content.

sysdba versus other user

Expand Messages
  • Mike Dewhirst
    I have found that I can create a database by offering ISC_USER = [owner] rather than SYSDBA. Is there anything special about SYSDBA? Is SYSDBA just a
    Message 1 of 11 , May 1, 2005
    • 0 Attachment
      I have found that I can create a database by offering ISC_USER = [owner]
      rather than SYSDBA.

      Is there anything special about SYSDBA?

      Is SYSDBA just a convention or is the ISC_USER at database creation
      time the real dba?

      Thanks

      mike
    • Alan McDonald
      ... SYSDBA is the server administrator. This identity has access to everything governed by the server. It s best practice, though, to create your databases
      Message 2 of 11 , May 1, 2005
      • 0 Attachment
        > I have found that I can create a database by offering ISC_USER = [owner]
        > rather than SYSDBA.
        >
        > Is there anything special about SYSDBA?
        >
        > Is SYSDBA just a convention or is the ISC_USER at database creation
        > time the real dba?
        >
        > Thanks
        >
        > mike

        SYSDBA is the server administrator. This identity has access to everything
        governed by the server. It's best practice, though, to create your databases
        with another user identity. Objects inside the database can be owned by yet
        other users if you wish.
        But at all times, SYSDBA will be able to access all objects, backup and
        restore the database. The owner will also be able to backup and restore its
        database but this non-SYSDBA identity will not be able to backup a database
        for which it is not the owner.
        Alan
      • Helen Borrie
        ... SYSDBA is a real user (the server s superuser). It has complete destructive rights over all databases, whether it owns them or not. ... I don t really
        Message 3 of 11 , May 1, 2005
        • 0 Attachment
          At 06:18 PM 1/05/2005 +1000, you wrote:
          >I have found that I can create a database by offering ISC_USER = [owner]
          >rather than SYSDBA.
          >
          >Is there anything special about SYSDBA?
          >
          >Is SYSDBA just a convention

          SYSDBA is a real user (the server's superuser). It has complete
          destructive rights over all databases, whether it owns them or not.

          >or is the ISC_USER at database creation
          >time the real dba?

          I don't really understand the question. ISC_USER and ISC_PASSWORD are
          environment variables that you can set (with caution!!) to the username and
          password respectively that you want to use at the command line. Usually,
          you set them temporarily in your private environment as the SYSDBA and its
          password, in order to do administrative command-line tasks without needing
          to enter them as command-line switches.

          ./heLen
        • Mike Dewhirst
          ... Sorry Helen - I wasn t clear enough. I was calling ddl scripts (actually, empddl.sql downloaded from the apress site and cut into separate parts) from a
          Message 4 of 11 , May 1, 2005
          • 0 Attachment
            Helen Borrie wrote:
            > At 06:18 PM 1/05/2005 +1000, you wrote:
            >
            >>I have found that I can create a database by offering ISC_USER = [owner]
            >>rather than SYSDBA.
            >>
            >>Is there anything special about SYSDBA?
            >>
            >>Is SYSDBA just a convention
            >
            >
            > SYSDBA is a real user (the server's superuser). It has complete
            > destructive rights over all databases, whether it owns them or not.
            >
            >
            >>or is the ISC_USER at database creation
            >>time the real dba?
            >
            >
            > I don't really understand the question. ISC_USER and ISC_PASSWORD are
            > environment variables that you can set (with caution!!) to the username and
            > password respectively that you want to use at the command line. Usually,
            > you set them temporarily in your private environment as the SYSDBA and its
            > password, in order to do administrative command-line tasks without needing
            > to enter them as command-line switches.

            Sorry Helen - I wasn't clear enough. I was calling ddl scripts
            (actually, empddl.sql downloaded from the apress site and cut into
            separate parts) from a bash script which set ISC_USER and ISC_PASSWORD.
            I want to put the ddl scripts under version control without including
            passwords. The bash script won't be versioned until I figure out how to
            make it request the password when it runs. It uses export and those ISC_
            vars evaporate when it exits.

            So the question relates to using a non-SYSDBA user to create the
            database. Alan responded that it is good practice to do so.

            Might be asking another question about gsec and those vars later.

            Mike
          • Mike Dewhirst
            ... Alan - thanks. That specifically answers my poorly phrased question. Objects inside the database can be owned by yet ... And - I just read in TFB that
            Message 5 of 11 , May 1, 2005
            • 0 Attachment
              Alan McDonald wrote:
              >>I have found that I can create a database by offering ISC_USER = [owner]
              >>rather than SYSDBA.
              >>
              >>Is there anything special about SYSDBA?
              >>
              >>Is SYSDBA just a convention or is the ISC_USER at database creation
              >>time the real dba?
              >>
              >>Thanks
              >>
              >>mike
              >
              >
              > SYSDBA is the server administrator. This identity has access to everything
              > governed by the server. It's best practice, though, to create your databases
              > with another user identity.

              Alan - thanks. That specifically answers my poorly phrased question.

              Objects inside the database can be owned by yet
              > other users if you wish.
              > But at all times, SYSDBA will be able to access all objects, backup and
              > restore the database. The owner will also be able to backup and restore its
              > database but this non-SYSDBA identity will not be able to backup a database
              > for which it is not the owner.

              And - I just read in TFB that SYSDBA is created upon installation -
              which answers my flipside question about where these userids are stored.
              My reading is that there is a server specific database for all the
              userids no matter how many application databases there might be.
              Permissions and rights to objects in any database are stored in the
              server's own private database. This was really a question not a
              statement :) ??

              Mike
            • Alan McDonald
              ... yes. It s called security.fdb. It s not that private. the services API will tell you where exactly it is on any server, as long as you know the SYSDBA
              Message 6 of 11 , May 1, 2005
              • 0 Attachment
                > Objects inside the database can be owned by yet
                > > other users if you wish.
                > > But at all times, SYSDBA will be able to access all objects, backup and
                > > restore the database. The owner will also be able to backup and
                > restore its
                > > database but this non-SYSDBA identity will not be able to
                > backup a database
                > > for which it is not the owner.
                >
                > And - I just read in TFB that SYSDBA is created upon installation -
                > which answers my flipside question about where these userids are stored.
                > My reading is that there is a server specific database for all the
                > userids no matter how many application databases there might be.
                > Permissions and rights to objects in any database are stored in the
                > server's own private database. This was really a question not a
                > statement :) ??
                >
                > Mike
                >

                yes. It's called security.fdb. It's not that private. the services API will
                tell you where exactly it is on any server, as long as you know the SYSDBA
                password.
                You cannot change the userid SYSDBA to anything else.
                Maybe you should read the metadata/security paper by Geoff Worboys on the
                firebordSQL website.

                Alan
              • Patrick Antonioli
                What is the url from this site (firebordSQL) ? Patrick ... [Non-text portions of this message have been removed]
                Message 7 of 11 , May 1, 2005
                • 0 Attachment
                  What is the url from this site (firebordSQL) ?

                  Patrick

                  2005/5/1, Alan McDonald <alan@...>:
                  >
                  > > Objects inside the database can be owned by yet
                  > > > other users if you wish.
                  > > > But at all times, SYSDBA will be able to access all objects, backup
                  > and
                  > > > restore the database. The owner will also be able to backup and
                  > > restore its
                  > > > database but this non-SYSDBA identity will not be able to
                  > > backup a database
                  > > > for which it is not the owner.
                  > >
                  > > And - I just read in TFB that SYSDBA is created upon installation -
                  > > which answers my flipside question about where these userids are stored.
                  > > My reading is that there is a server specific database for all the
                  > > userids no matter how many application databases there might be.
                  > > Permissions and rights to objects in any database are stored in the
                  > > server's own private database. This was really a question not a
                  > > statement :) ??
                  > >
                  > > Mike
                  > >
                  >
                  > yes. It's called security.fdb. It's not that private. the services API
                  > will
                  > tell you where exactly it is on any server, as long as you know the SYSDBA
                  > password.
                  > You cannot change the userid SYSDBA to anything else.
                  > Maybe you should read the metadata/security paper by Geoff Worboys on the
                  > firebordSQL website.
                  >
                  > Alan
                  >
                  >
                  > Yahoo! Groups Links
                  >
                  >
                  >
                  >
                  >


                  [Non-text portions of this message have been removed]
                • Adam
                  lol, you are going to have trouble finding it on the firebord site :) The direct link is here: http://www.firebirdsql.org/index.php?
                  Message 8 of 11 , May 1, 2005
                  • 0 Attachment
                    lol, you are going to have trouble finding it on the firebord site :)

                    The direct link is here:

                    http://www.firebirdsql.org/index.php?
                    op=doc&sub=contrib&id=fb_meta_security

                    Bookmark the article. Worth the read.

                    Or you can just browse the FAQ to question 20

                    http://www.firebirdsql.org/index.php?op=faq#q0020.dat

                    Adam

                    --- In firebird-support@yahoogroups.com, Patrick Antonioli
                    <patrick.antonioli@g...> wrote:
                    > What is the url from this site (firebordSQL) ?
                    >
                    > Patrick
                    >
                    > 2005/5/1, Alan McDonald <alan@m...>:
                    > >
                    > > > Objects inside the database can be owned by yet
                    > > > > other users if you wish.
                    > > > > But at all times, SYSDBA will be able to access all objects,
                    backup
                    > > and
                    > > > > restore the database. The owner will also be able to backup
                    and
                    > > > restore its
                    > > > > database but this non-SYSDBA identity will not be able to
                    > > > backup a database
                    > > > > for which it is not the owner.
                    > > >
                    > > > And - I just read in TFB that SYSDBA is created upon
                    installation -
                    > > > which answers my flipside question about where these userids
                    are stored.
                    > > > My reading is that there is a server specific database for all
                    the
                    > > > userids no matter how many application databases there might be.
                    > > > Permissions and rights to objects in any database are stored in
                    the
                    > > > server's own private database. This was really a question not a
                    > > > statement :) ??
                    > > >
                    > > > Mike
                    > > >
                    > >
                    > > yes. It's called security.fdb. It's not that private. the
                    services API
                    > > will
                    > > tell you where exactly it is on any server, as long as you know
                    the SYSDBA
                    > > password.
                    > > You cannot change the userid SYSDBA to anything else.
                    > > Maybe you should read the metadata/security paper by Geoff
                    Worboys on the
                    > > firebordSQL website.
                    > >
                    > > Alan
                    > >
                    > >
                    > > Yahoo! Groups Links
                    > >
                    > >
                    > >
                    > >
                    > >
                    >
                    >
                    > [Non-text portions of this message have been removed]
                  • Helen Borrie
                    ... http://www.firebirdsql.org Look in the Knowledgebase section (from Resources item on the top menu). ./hb
                    Message 9 of 11 , May 1, 2005
                    • 0 Attachment
                      At 09:02 PM 1/05/2005 -0300, you wrote:
                      >What is the url from this site (firebordSQL) ?

                      http://www.firebirdsql.org

                      Look in the Knowledgebase section (from Resources item on the top menu).

                      ./hb
                    • Milan Babuskov
                      ... You can use read to get value into variable. read -p Enter username: ISC_USER read -p Enter password: ISC_PASSWORD ... If you wish them to stay,
                      Message 10 of 11 , May 3, 2005
                      • 0 Attachment
                        Mike Dewhirst wrote:
                        > Sorry Helen - I wasn't clear enough. I was calling ddl scripts
                        > (actually, empddl.sql downloaded from the apress site and cut into
                        > separate parts) from a bash script which set ISC_USER and ISC_PASSWORD.
                        > I want to put the ddl scripts under version control without including
                        > passwords. The bash script won't be versioned until I figure out how to
                        > make it request the password when it runs.

                        You can use "read" to get value into variable.

                        read -p "Enter username: " ISC_USER
                        read -p "Enter password: " ISC_PASSWORD

                        > It uses export and those ISC_
                        > vars evaporate when it exits.

                        If you wish them to stay, you can use "source" in the script calling it. Or
                        call it from bash directly:

                        source ./script.sh

                        I know this is OT, but I hope it helps.

                        --
                        Milan Babuskov
                        http://fbexport.sourceforge.net
                        http://www.flamerobin.org
                      • Mike Dewhirst
                        ... cool Thank you Mike
                        Message 11 of 11 , May 3, 2005
                        • 0 Attachment
                          Milan Babuskov wrote:
                          > Mike Dewhirst wrote:
                          >
                          >>Sorry Helen - I wasn't clear enough. I was calling ddl scripts
                          >>(actually, empddl.sql downloaded from the apress site and cut into
                          >>separate parts) from a bash script which set ISC_USER and ISC_PASSWORD.
                          >>I want to put the ddl scripts under version control without including
                          >>passwords. The bash script won't be versioned until I figure out how to
                          >>make it request the password when it runs.
                          >
                          >
                          > You can use "read" to get value into variable.
                          >
                          > read -p "Enter username: " ISC_USER
                          > read -p "Enter password: " ISC_PASSWORD

                          cool

                          Thank you

                          Mike

                          >
                          >
                          >>It uses export and those ISC_
                          >>vars evaporate when it exits.
                          >
                          >
                          > If you wish them to stay, you can use "source" in the script calling it. Or
                          > call it from bash directly:
                          >
                          > source ./script.sh
                          >
                          > I know this is OT, but I hope it helps.
                          >
                        Your message has been successfully submitted and would be delivered to recipients shortly.