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.
- What does the xs$null account actually do
- 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]
You upgraded to 11gR2
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.
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 220.127.116.11 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 18.104.22.168 an additional fix was introduced’ , in the past tense, which is interesting because 22.214.171.124 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 126.96.36.199 (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 188.8.131.52 but not do anything with it in 184.108.40.206
220.127.116.11 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 18.104.22.168 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