Mac OS 9 Multiple Users Security Vulnerabilities

Introduced in 1999, Mac OS 9 brought the Multiple Users feature to Apple's classic operating system, attempting to provide distinct environments for different users on shared home and classroom computers. However, because classic Mac OS was built on an aging architecture without modern access controls, the feature suffered from severe security vulnerabilities. This article examines the architectural flaws, boot bypasses, and file system weaknesses that made Multiple Users security largely superficial.

Lack of Memory Protection and Kernel-Level Security

Classic Mac OS used a cooperative multitasking model with a flat memory space and no protected memory. Under this architecture, the Multiple Users feature functioned merely as an application-level layer within the System Folder rather than an enforced kernel privilege system. Any program executed by a restricted user shared the exact same memory space as core system components. A user running unauthorized code or custom scripts could directly read from or write to memory belonging to other users or the operating system itself.

Bypass via Alternative Booting and Extension Management

The Multiple Users security framework relied entirely on system extensions and control panels loading during the standard boot cycle. This implementation created several trivial physical bypasses:

• Extensions Off (Shift-Key Boot): Holding down the Shift key during startup disabled all system extensions, completely disabling the Multiple Users login screen and booting the machine directly into an unrestricted desktop environment.
• Removable Media Booting: Booting the computer from a secondary storage device, such as a bootable Mac OS CD-ROM, Zip disk, or external SCSI/FireWire drive, completely ignored the access controls configured on the internal hard drive.

Absence of File System-Level Permissions

Unlike modern Unix-based systems or Windows NT, classic Mac OS used the standard HFS and HFS+ file systems without native POSIX-style file permissions. The restrictions defining what a "Limited" or "Panels" user could see were enforced solely by the Finder. Because the disk itself lacked access control lists (ACLs) or native file ownership:

• Moving files to an external disk or viewing them through another application bypassed Finder-level restrictions.
• Any software capable of directly addressing the volume structure could read, modify, or delete files belonging to the "Owner" account.

Standard Open and Save Dialog Exploits

The Multiple Users environment attempted to lock down users through simplified interfaces like "Panels," which restricted execution to specific approved applications. However, standard Mac OS Navigation Services (the file Open/Save dialog boxes) did not consistently inherit these restrictions. A user inside an authorized application could often use the "Open" dialog to navigate freely through the system directory tree, access restricted documents, or launch external executables by opening associated document types.

Weak Credential and Configuration Storage

User profiles, access privileges, and account metadata were stored in standard preference files inside the System Folder. Because file-level encryption was not deeply integrated into the OS—FileGuard-like protections were absent natively—an unauthorized user who obtained read access to the drive could easily extract or replace the preferences file to reset the master account password or elevate account privileges to Owner status.