The Downsides Of Read-Only Filesystems

Previously I discussed the benefits of using read-only filesystems to restore your computers. While it is a great concept, there are some drawbacks:

– Not everyone can play

Although great on paper, read-only setup is primarily a Linux game.

– Patching becomes a chore

In order to patch a system, the read-only FS needs to be re-mounted in writeable mode. If the media is non-writable, such media needs to be replaced. As long as systems are left unpatched, no user information is secure and such compromised end nodes can be used to stage further attacks.

– Interoperability will suffer

Programs often keep vital configuration and operational data close by, inability to write such data might lead to numerous programs behaving abnormally, leading to potential system instability.

– Nothing is written in stone

Using a writeable medium mounted in read-only mode does not really reduce potential for vulnerability, as such volume can be re-mounted in writeable mode, so any changes can be saved permanently.

– Logs might be a problem

Given that the core system FS is read-only, it will be necessary to make sure that all logs are reviewed and re-linked to a writeable system. Quite often one can find logs outside the traditional /var/log directory.

– Adding new programs will get tricky

Not only patching existing applications will be difficult, getting anything new onto such read-only system will be problematic. If one needs to deploy a new application, the deployment will require the FS to get re-mounted, or completely replaced if it is represented by hardware that is not writeable.

– “Can’t touch this” MC Hammer style is annoying to end users

If a user does not have the rights to write to a specific location, or to access it, the OS notifies such user in a conventional way. If, however, a user tries to save something to a location s/he has access to, but the action fails due to the read-only nature of the underlying filesystem, the user will most likely perceive such behavior as system error and will definitely get annoyed. The behavior is not expected, so users will be confused, start to complain and call support.

Dmitry Shesterin

Dmitry has done everything. From sales and marketing in mobile telecommunications and printing (in Russia and Germany) to sales engineer and marketing lead (at Faronics). Dmitry has an unrivaled love of Excel and his sense of humor resembles Ambrose Bierce, his favorite writer.