IC72257: REMOTE SPL EXECUTION SHOULD ONLY BE ALLOWED IN RESTRICTED MODE FOR USER WITH APPROPRIATE REMOTE PRIVILEGES

APAR status

• Closed as program error.

Error description

• STEPS:
  
  We need 2 users to see the bug (user informix and another
  one...)
  
  Run the testcase below as user informix.
  
  As another user connect to DB_1 and try to execute procedure
  test_proc1().
  It should raise error -674 which is correct.
  
  As that user connect to DB_2 and try to execute procedure
  test_proc2().
  It should raise error -674 on proc_test1 which is correct.
  
  As user informix grant DBA to that user on db_2.
  Repeat step 3.  It will work, and it shouldn't :
  
  Why does the fact that he's DBA in db_2 allow him to run the
  procedure in db_1?
  This is a security issue.
  
  DISCUSSION:
  
  Sysprocedures Documentation:
  
  mode CHAR(1) Mode type:
  D or d = DBA
  O or o = Owner
  P or p = Protected
  R or r = Restricted
  T or t = Trigger
  
  "In the mode column, the R mode is a special case of the O mode.
  
  A routine is in restricted (R) mode if it was created with a
  specified owner who is different from the routine creator.
  If routine statements involving a remote database are executed,
  the database server uses the access privileges of the user
  who executes the routine instead of the privileges of the
  routine owner.
  In all other scenarios, R-mode routines behave the same as
  O-mode routines."
  
  Restricted mode procedures exist only because we don't "trust" a
  DBA
  that can create a procedure in name of other user.
  As such It doesn't make sense that a DBA on db_2 can execute a
  procedure
  on db_1 when that procedure does not have any grant that allows
  him to run it directly.
  
  dba, resource and connect are database level privileges
  A 'dba' is a special user in it's database. Not in others.
  Informix is a special case. it's by default dba in all
  databases.
  No other user has that privileges.
  
  
  TESTCASE:
  
  database sysmaster;
  drop database db_1;
  drop database db_2;
  create database db_1 with log;
  create database db_2 with log;
  
  -- database db_1
  database db_1;
  grant connect to public;
  
  -- Simplest procedure. No grants. Only DBAs would be allowed to
  run it
  create procedure test_proc1()
  end procedure;
  
  revoke execute on test_proc1 from public;
  
  database db_2;
  grant connect to public;
  
  
  -- Simple "restricted mode" procedure. Grant execute to public
  on test_proc2
  -- should raise error 674 when calling test_proc1 because being
  a restricted mode
  -- procedure means it will run remote operations with the real
  user identity
  
  create procedure "proc_owner".test_proc2()
          call db_1:test_proc1();
  end procedure;
  
  grant execute on test_proc2 to public as "proc_owner";
  
  
  -- After seeing error 674 give dba to your second test user on
  db_2
  -- Then call the procedure test_proc2 again. It will run even
  test_proc1() which
  -- does not have execute privileges
  --grant dba to your_second_user;
  
  
  This reproduced in 10.00.UC10, 11.10.UC3, 11.50.UC7
  
  
  
  The problem does not reproduce if db_1 and db_2 databases are
  created in different instances
  Note: this is not a regression of IC64678 (idsdb00194831).
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * 11.50xC8 and prior                                           *
  * 11.70.xC1 and prior                                          *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * If an user is granted DBA privileges for a database, then    *
  * this user would be able to remotely execute procedures of    *
  * another database in the same instance for which he is not    *
  * explicitly granted permissions.                              *
  ****************************************************************
  * RECOMMENDATION:                                              *
  * Please upgrade to IDS version 11.50xC9 or later.             *
  ****************************************************************
  

Problem conclusion

• In case of a database context switch internally, the
  permissions for the new database would be effective for the
  user. This behavior would be available from 11.50xc9.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  IBM IDS ENTRP E

• Fixed component ID

  5724L2304

Applicable component levels

• RB15 PSY

     UP