Ensuring the accessibility of the system for disaster recovery without downtime
Publication Date: 2016-Apr-13
The IP.com Prior Art Database
An operating system (OS) can become inaccessible when identification/authentication related data gets lost/corrupted or if there is an issue in a puggable authentication module itself (issue as part of the login process). In this situation downtime becomes inevitable and a system administrator will have to go to maintaince mode to restore the accessibility of the system. Entering the maintaince mode kills all the processes on the system as a reboot is involved. Note that only access to the OS is an issue, and other processes would be running normally. To overcome such a situation, a need arises for a mechanism which gives access to the system without interrupting the normal business.
This approach recognizes a method to recover a system from the said issues by having a limited privileged user, also referred as "recovery user" in this document. This user will have the capability to perform recovery activities. This approach explains when this user is created, how to preserve the credentials of the recovery user, and also how and when to grant this user access to the operating system.
Page 01 of 4
Ensuring the accessibility of the system for disaster recovery without downtime Disclosed is a method that addresses the issue of access recovery without downtime of an operating system(OS). The OS in question has only lost its ability to grant access to any OS users including the system administrators. But, all other end user applications would be functioning properly and network accessibility to these applications are available to the application end users. This method involves creation of a limited privilege user, "recovery" user who can only perform recovery activities. This user will be created when the system boots up for the first time and this user's credentials will be stored in the binary format in a restricted file system. Whenever system becomes inaccessible, this user can login with proper credentials and perform the necessary recovery actions from the backup.
With this approach, there is no need to bring the system to maintenance mode and spend time and effort to bring it back to normal state. All that needs to be done is, login via recovery user and fetch the backup files on to the system. This approach relies on the timely backup of the security files taken by the administrator /owner of the system. This approach recognizes root enabled and root disabled system which will be enabled for disaster recovery by virtue of recovery user.
Working of recovery user :
During the first boot , the recovery user will be created and the administrator will be prompted for a password. These credentials will be stored in a restricted file system in binary format as well as with the security data of other users in the current security files. A restricted file system is an area on the disk to which access by any user process apart from the recovery/root user's process, is restricted. Authentication for this recovery user has to be done via the credential file in the restricted file system.
The rationale of saving the credentials of a recovery user with security data of other users:
This prevents creation of a new user with same name or id as the recovery user. If the recovery user entry is not added in normal security files (/etc/security/user, /etc/security/passwd, /etc/group, /etc/passwd etc... ), there is a possibility that another normal user with same user id and group id can be created. By virtue of these ids, the new user can perform the recovery user operation as the DAC permissions of the recovery program will allow this new user to run the recovery process, which is a security flaw.
The authentication of the recovery user happens as below:
At the system boot time, the credentials of the recovery user will be pushed into the kernel. Whenever the identification or authentication related data are lost or corrupted, use this recovery user to login to the system. When authentication for this user needs to happen, the login credentials will be fetched from kernel and authentication is done using the same.
The below picture depic...