Results 1 to 5 of 5
  1. #1
    Join Date
    Apr 2014
    Posts
    4

    Unanswered: Informix Public Role

    Hi Guys

    I am not a tech guy, I am actually a Chartered Accountant who has moved over to advisory.

    In my firm, we are required to perform technical reviews by providing scripts and analysing the results. Informix is not a DB that we come across very often.

    In my current audit we have noted that the Public role has been granted D access, therefore they have DBA privileges.

    Is there any reason that any of you who have experience on Informix can think of as to why Public would require D privilege?

    I am asking so that if the client comes back to me and says they require that access for business purposes, I would like to be able to give my relevant input.

  2. #2
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    The "D" privilege returned by querying systabauth is Delete.

    The "D" value in the sysusers.usertype indicates a DBA, meaning that the user has every privilege.

    I can't come up with a good general reason for making PUBLIC a DBA. That seems like a quick way to accomplish a disaster.

    I'm a big fan of the "principle of least privilege" which says every user has exactly the permissions that are needed for their work, and nothing more. I'm also a big fan of having every user have a unique login (no sharing of credentials) so that database auditing can be performed (which is only vaguely related to financial auditing).

    One possible alternative if the client wasn't willing to actively manage security would be to restrict the DBA role then make PUBLIC the owner of all tables. This would give every user read/write access to the tables, but would at least limit the carnage a bit.

    -PatP
    In theory, theory and practice are identical. In practice, theory and practice are unrelated.

  3. #3
    Join Date
    Apr 2014
    Posts
    4
    Quote Originally Posted by Pat Phelan View Post
    The "D" privilege returned by querying systabauth is Delete.

    The "D" value in the sysusers.usertype indicates a DBA, meaning that the user has every privilege.

    I can't come up with a good general reason for making PUBLIC a DBA. That seems like a quick way to accomplish a disaster.

    I'm a big fan of the "principle of least privilege" which says every user has exactly the permissions that are needed for their work, and nothing more. I'm also a big fan of having every user have a unique login (no sharing of credentials) so that database auditing can be performed (which is only vaguely related to financial auditing).

    One possible alternative if the client wasn't willing to actively manage security would be to restrict the DBA role then make PUBLIC the owner of all tables. This would give every user read/write access to the tables, but would at least limit the carnage a bit.

    -PatP
    Hi Pat,

    Thanks for the response.

    It is definitely sysusers. I am in agreement with your privielege philosophy and all users do have unique IDs. Database auditing is an important part of the Financial Audit as it gives the financial audit team the comfort that there is some degree of accountability if something were to go wrong. I was initially based on Financial Audit for 3 years but have no moved over to the IT space where we provide comfort over the general IT controls at an entity and specific applications which provides financial audit with the ability to rely on the General IT environment and the reports obtained from the relevant systems. Just some uselss info.

    Back to the point.

    For some reason public has been granted DBA privileges when all they need is "C" (Connect).

    There is already issues regarding the administrators administering both OS and DB which has already been noted, however due to the age of the system I believe the business are willing to accept these risks.

    Thanks again for your prompt response.

  4. #4
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    Keep in mind that unless your client is running a VERY old version of Informix, the Connect privilege is exactly what the name sounds like... It gives the user the ability to connect to the database, but not to do anything more.

    If you want the users to only have SELECT privileges, those will need to be explicitly granted to either public or to a role. Without knowing specifics about your engagement, in order to keep "read only" access for every user I'd suggest creating a "Read only" role and grant that role SELECT permissions on every table and view. That way the procedure of adding a user to the database becomes:
    1. Grant Connect
    2. Add user to "Read Only" role
    3. If appropriate, add user to other roles
    -PatP
    In theory, theory and practice are identical. In practice, theory and practice are unrelated.

  5. #5
    Join Date
    Apr 2014
    Posts
    4
    Quote Originally Posted by Pat Phelan View Post
    Keep in mind that unless your client is running a VERY old version of Informix, the Connect privilege is exactly what the name sounds like... It gives the user the ability to connect to the database, but not to do anything more.

    If you want the users to only have SELECT privileges, those will need to be explicitly granted to either public or to a role. Without knowing specifics about your engagement, in order to keep "read only" access for every user I'd suggest creating a "Read only" role and grant that role SELECT permissions on every table and view. That way the procedure of adding a user to the database becomes:
    1. Grant Connect
    2. Add user to "Read Only" role
    3. If appropriate, add user to other roles
    -PatP
    Thank Pat.

    I will keep that in mind during our clearance meeting.

    The informix version is 7.31.UD8

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •