Matthew Roessner
asked on
Access to SYSIBM tables
What kind of authority does a user need to be able to run queries against the SYSIBM tables on the iSeries? Our programmers need me to set up a user for them - but I want to give the least amount of authority as possible - while still being able to query the tables in SYSIBM.
I appreciate the help
I appreciate the help
ASKER
Found the following command which solved my issue:
RUNSQL SQL('GRANT SELECT ON TABLE SYSIBM.SYSDUMMY1 TO USERNAME')
RUNSQL SQL('GRANT SELECT ON TABLE SYSIBM.SYSDUMMY1 TO USERNAME')
ASKER
I've requested that this question be closed as follows:
Accepted answer: 0 points for hfcsp's comment #a41151864
for the following reason:
While awaiting a response - continued to search the internet for a solution and found the command that I needed to grant access to the table.
Accepted answer: 0 points for hfcsp's comment #a41151864
for the following reason:
While awaiting a response - continued to search the internet for a solution and found the command that I needed to grant access to the table.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Hi Matthew,
SYSIBM.SYSDUMMY1 isn't a real table. It's a catch-all name that adds capability to DB2 that also exists in Oracle and SQL Server (and others).
I'm absolutely shocked that the default behavior of DB2 restricts access to that name. It seems like more of a bug in DB2 than a feature. What version of DB2 and O/S are you running?
Kent
SYSIBM.SYSDUMMY1 isn't a real table. It's a catch-all name that adds capability to DB2 that also exists in Oracle and SQL Server (and others).
I'm absolutely shocked that the default behavior of DB2 restricts access to that name. It seems like more of a bug in DB2 than a feature. What version of DB2 and O/S are you running?
Kent
Thanks for a great explanation, Gary.
That scenario never occurred to me. :)
Kent
That scenario never occurred to me. :)
Kent
I encourage clients to secure SYSIBM (and other database metadata), since it provides so much information about the database, and by default can be read by anyone with a profile and a way to execute a query or otherwise access the tables/views.
*PUBLIC=*READ offers an attacker who may have obtained only the most restricted end user credentials the opportunity to gather a lot of information about the database. An attacker can query the list of schemas, for example, and obtain clues about third-party products installed on the system - some of which may have known vulnerabilities or may create privileged IDs with well-known default passwords. Table names may give clues to the location of sensitive information. Stored procedure names may provide clues to ways to access sensitive data or elevated operations.
*PUBLIC=*READ offers an attacker who may have obtained only the most restricted end user credentials the opportunity to gather a lot of information about the database. An attacker can query the list of schemas, for example, and obtain clues about third-party products installed on the system - some of which may have known vulnerabilities or may create privileged IDs with well-known default passwords. Table names may give clues to the location of sensitive information. Stored procedure names may provide clues to ways to access sensitive data or elevated operations.
Your programmers (with DB2 access) should be able to query the SYSIBM tables without any special permissions. They cannot write directly to these tables, but read access should be the default.
Kent