Before the introduction of the registry, all of this information was stored in literally hundreds of individual .ini (initialization) files. With such an arrangement, there was usually at least one .ini file per program, and they were scattered throughout the file directory. The registry was introduced to create a single repository for system and application configurations.
The registry in Windows stores data in binary format, keeping the configuration data for the machine and its users in separate files. This allows the system and its applications to load global and individual configurations upon startup and login. One major advantage of the registry is that configuration backup and restore actions involve only a small number of files in known locations. Another benefit is that administrators can use Group Policy to centrally manage program and policy settings. Such an arrangement allows administrators to set an entry in the registry for all the computers on a network. Generally, storing configuration data in a database is a good idea, as long as it can be well-protected. Standardizing how data is stored makes it easier to push configuration data to potentially thousands of users.
The problem with a centralized registry, however, is that the information is located in one place, and that location is an attractive target for hackers. A number of registry vulnerabilities have been exploited over the years. As part of a system hardening routine, ACL permissions should be configured to lock down remote registry access and limit user access to keys.
Another concern is that the HKEY_LOCAL_MACHINE section of the registry is a single point of failure that can leave a Windows system unbootable. Microsoft has worked to make the registry more stable, self-maintaining and self-repairing, but as the registry inevitably grows, it slows down the computer's startup and can make it unstable. To ease this problem, the Mac OS X operating system typically stores application settings in standard flat files using the XML format. An advantage of this approach is that corruption to one of these files will normally only affect a single application, whereas corruption of one of the Windows registry files can have wide-reaching effects. OS X also has a system database called NetInfo that stores system-wide settings such as user account details and network configuration.
Linux operating systems store configuration information in flat text files that are grouped together: the /etc directory used for host-specific system configuration data and the /var directory used for variable configuration data. There is a chance that this approach will also give way to XML.
Sun Microsystems' Solaris operating system takes a network-centric approach. System information, such as passwords, network services and IP addresses, is stored in XML namespaces that can be accessed via a network repository service, such as Network Information System (NIS) or a Lightweight Directory Access Protocol (LDAP) directory. User-specific information, such as profiles and desktop preferences, is stored in files located in home directories. The data is accessed via the Network File System (NFS) or a local directory (if the machine is disconnected).
At the end of the day, there is no ideal approach for storing operating system and application configuration data. Each option has different benefits, and users and administrators are often forced to choose between security and ease of use.
Dig Deeper on Active Directory and LDAP Security
Related Q&A from Michael Cobb
The increasing popularity of bug bounty programs leaves many wondering if they can improve enterprise software security. Expert Michael Cobb ...continue reading
Expert Michael Cobb explains how password change frequency and reuse for third-party apps should be addressed in enterprise password policies.continue reading
Learn how a Web-based free spam-filtering service can secure email and prevent spam from attacking your enterprise.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.