Oracle DBA – A lifelong learning experience

database user xs$null

Posted by John Hallas on February 18, 2013

When we put a new system into production we get the whole set of infrastructure penetration tested. Reading a recent review I saw the following recommendation as part of the database section.

XS$null Recommendation:
Ensure the XS$NULL account is not set to the default password even though it is locked.
That brought two things to mind.
  1. What does the xs$null account actually do
  2.  If an account is locked why is the default password such an issue

The focus of this article is to share some information about the xs$null account and then to ponder the changing of a default password on a locked account.

The oracle documentation for that user states

An internal account that represents the absence of a user in a session. Because XS$NULL is not a user, this account can only be accessed by the Oracle Database instance. XS$NULL has no privileges and no one can authenticate as XS$NULL, nor can authentication credentials ever be assigned to XS$NULL.

Which is enough to tell me that changing the password probably will not make a difference to any internal usage of that account that is supported by a MoS note which says  (in my simplified words) – don’t try to do anything with this account

When you try to alter user XS$NULL (for example to switch to another profile or to unlock it) you get the following error:

SQL> alter user xs$null profile default;
alter user xs$null profile default
*
ERROR at line 1:
ORA-01031: insufficient privileges

When you dump a callstack for this error you will discover it is raised from kzuial():

alter session set events ‘1031 trace name errorstack level 3′;
alter user xs$null profile default;

……

full trace dump details can be viewed in MoS note  – Cannot Alter User XS$NULL [ID 1325766.1]

Changes

You upgraded to 11gR2

Cause

In 11.2 development explicitly added a check in the code to make sure that nobody (not even user SYS) can alter user XS$NULL. This is the expected behaviour.

Solution

You cannot alter user XS$NULL. This is the expected behaviour. User XS$NULL is internal and it may not be altered in any way. To guarantee the stability of the system, this was explicitly forbidden.

Even if this may work in earlier releases it is strongly recommended to not alter user XS$NULL.

If you try to do this because of some security auditing requirements (which for example demand that  all users should be in a certain profile) explain to the auditors that this is impossible.

Another reason why you may want this is to change the default tablespace of the user, while you cannnot alter this user specifically you can change the default tablespace at the database level and when you do this it will change the XS$NULL user temp tablespace as well.

In version 11.2.0.4 an additional fix to bug 12822989 was introduced that prevents the change of the password for internal user XS$NULL using the sqlplus ‘password’ command (or using the OCIPasswordchange call in general), please do not use the ‘password’ command in earlier releases to bypass the check, since it is unsupported to do so.

PS I do like the words ‘in 11.2.0.4 an additional fix was introduced’ , in the past tense, which is interesting because 11.2.0.4 is reputed to be the 11GR2 terminal release and is not scheduled for release until at least late into Q3 2013 as I understand the situation.

The release we are on for this database is 11.2.0.1 (supportability issues with the application is the main/only reason for that). So I will be going back with the response that the account is locked and we will not be changing it on Oracle’s advice.

PPS a little test shows that you can change account in 11.1.0.7 but not do anything with it in 11.2.0.3

11.1.0.7

SQL>select  username, profile from dba_users where username like 'XS%';

USERNAME                       PROFILE
------------------------------ ------------------------------
XS$NULL                        DEFAULT

SQL>alter user xs$null profile m_std_profile identified by  Changepass123;

User altered.

connect xs$null/Changepass123
ERROR:
ORA-28000: the account is locked
SQL>alter user xs$null account unlock;

User altered.

Connected.
SYS@MOMPTC2A SQL>connect xs$null/Changepass123
ERROR:
ORA-01017: invalid username/password; logon denied

11.2.0.3

SQL> select  username, profile from dba_users where username like 'XS%';

USERNAME                       PROFILE
------------------------------ ------------------------------
XS$NULL                        DEFAULT

SQL> alter user xs$null profile m_std_profile identified by  Changepass123;
alter user xs$null profile m_std_profile identified by  Changepass123
*
ERROR at line 1:
ORA-01031: insufficient privileges

Onto point 2. Now I am sure that there is a good reason to change a default password as well as locking the account but I fail to see it. My thought process would be that if someone has got into your database with enough privileges to unlock an account then changing a password is not going to be a big obstacle to them. Happy to have some explanation of that requirement. As the title of my  blog states – a lifelong learning experience

About these ads

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
Follow

Get every new post delivered to your Inbox.

Join 196 other followers

%d bloggers like this: