Cutting Off The Root: The Future Of Community Developed Android


The CyanogenMod team made news last week when they announced that future versions of their venerable Android build would no longer include root-level access by default, a massive departure from essentially every other custom Android ROM. Some have questioned the move, claiming that removing root undermines the very idea of running a custom ROM.

What is root, and do you really need it? Is CyanogenMod setting a trend, or doing their users a disservice?

What Is Root?

The concept of “root” goes all the way back to the UNIX days, when there was no such thing as a personal computer. Computers at the time were operated on a principle known as “time-sharing“, which meant that many users and organizations had to share a single system due to the enormous costs involved. In such a scenario, it was necessary to regulate what individual users were capable of, and make sure that no normal user could make system-wide changes that could effect the other users or groups who shared time on the same machine. The only user account which could make system-wide changes on such a computer was known as “root”, and access to this account was closely guarded.

As time went on, computers began to make the transition from mainframes which only the largest companies could afford to home systems which were solely operated by a single individual. In the new age of personal computing, the idea of the root account became something of a hindrance. Newer operating systems, like Microsoft Windows, took the root account concept and modified it into the “Administrator”. An Administrator account was similar to root in the sense that it had full control over the system, but also had some big differences. For example, in a UNIX-based operating system there can only ever be a single root user, but any number of users can be deemed Administrator under Windows.

In recent years, even the major desktop Linux distributions (such as Ubuntu) have begun limiting or even removing the root user. Rather than allowing the computer’s owner to login as root, something which is strongly advised against, these distributions temporarily elevate the rights of the normal user’s account using “sudo“. By giving a user temporary root-level access, after authenticating them with their own password, the computer owner is able to make select administrative changes without the security compromise of giving the user full time root-level permissions.

Root In Android

As Android is essentially a Linux variant, it inherits the root user concept and the idea that the device’s owner shouldn’t necessarily have absolute control over the hardware. It was this limitation specifically that lead early Android users to seek out a way of running applications as root on their devices. This allowed for many applications that wouldn’t otherwise have been possible, such as overclocking the processor or using the device as a WiFi access point. This ability has been able to breathe new life into older devices, and has been a staple of the custom ROM community for years.

Android ROMs which include root-level access (known as “rooted ROMs”) have employed a system very similar to what the desktop Linux distributions have been doing: prompting the user when an application is requesting higher than normal permissions to perform an action. It is designed to give the device user a very clear indication that something is happening on their device which needs their attention.

An application requesting root access via the "Superuser" tool

This arrangement has worked fairly well, but it is still all too easy for an unsuspecting user to allow an application root permissions. Written warnings go ignored far to often to be relied on.

Security Risk

As recent attacks against applications such as Google Wallet have shown, there is a serious security risk involved when allowing applications on a user’s device to be granted root permissions. Even with Superuser prompting when a new application is asking for root permissions, there is no guarantee that the end user truly understands what they are being asked and its implications. To this end, the CyanogenMod team have made the big decision to disable root access by default for their development version, CM9.

At CyanogenMod, security has always been one of our primary concerns, however, we were hesitant to make a change that might disrupt the current root ecosystem. With CyanogenMod 9 we have the opportunity to do things better, whether its the code in the OS, UI/UX, or security – we are taking this time to do things with a fresh approach.

Shipping root enabled by default to 1,000,000+ devices was a gaping hole. With these changes we believe we have reached a compromise that allows enthusiasts to keep using root if they so desire but also provide a good level of security to the majority of users.

CyanogenMod Team

Of course, root permissions can still be enabled under CM9 if the user wants them, but they will be enabled on a selective basis. Root permissions in CM9 won’t be an all-or-nothing proposition, users will be able to select if they want to enable root for ADB, applications, or both. Even when the user confirms they want applications to have access to root, they will still need to confirm each specific application through the existing Superuser prompts. This added level of protection should prevent anyone who doesn’t understand the implications of root from accidentally enabling it on their device.

Who Really Needs Root?

If CyanogenMod 9 will no longer offer the user root access by default, does that defeat the purpose of running CyanogenMod? The answer to that question isn’t exactly straight forward, as the nature of custom Android ROMs has changed drastically since the early days. When there were only a handful of Android devices on the market, custom ROMs were simply a way to personalize and tweak your device. But with the explosion of Android and the push towards releasing new devices rather than supporting older ones, putting a custom ROM on your device can be nearly a requirement.

The release of Android 4.0 “Ice Cream Sandwich” is an excellent example of how community developed ROMs can deliver on promises the manufacturer’s don’t keep. With big name players such as a Motorola and HTC failing to provide timely updates of their devices to the latest version of Android, the end user is left with few choices. Buy the latest device which your manufacturer of choice still feels like supporting (for the time being), or jump ship and switch over to a build of Android that is maintained by others who are in your same predicament.

For these users, the motivation for running a ROM like CyanogenMod isn’t to push their phone to the absolute limits, but to simply be able to use the latest version of Android on the device they paid good money for. These users aren’t interested in the intricacies of custom Android builds, they just don’t want to have to buy a new device every 6 to 8 months to feel relevant.

The Future Of Community ROMs

With over 1 million devices running CyanogenMod, and untold numbers running ROMs based on it; community developed Android has officially graduated from niche status. As device manufacturer’s wake up and lower the hurdles involved in putting alternative firmware on their devices, even non-technical users will be joining the scene. In the future, we may even see smaller manufacturers actually shipping their devices with CyanogenMod (or a derivative) rather than taking the time and money to develop their own builds.

With these new elements in mind, it’s more important than ever to make sure community developed ROMs are not only delivering the performance and customization we’ve come to know and love, but also security and piece of mind. Developing a ROM which puts a non-technical user in danger of destroying their device or compromising their identity does nothing to further the goals of the community or establish these ROMs as legitimate alternative’s to the manufacturer supplied images.

About Tom Nardi

Tom is a Network Engineer with focus on GNU/Linux and open source software. He is a frequent submitter to "2600", and maintains a personal site of his projects and areas of research at: .