If verity is enabled and the underlying block device is marked
read-only, disable-verity fails. We cannot use the existing code
for enable-verity to make the device writable as the device in
/proc/mounts will be the verity device instead of the underlying
device we want to change. This change makes the correct device
writable when altering verity state.
Change-Id: I423ee50fb34d78cff2fe843318b9081c03c5142d
Note that it is *easy* to break your phone with this feature. It is
not a bug that reenabling verity after changing one byte of the system
partition stops the device booting.
(cherry-pick of 7c442e1700e6312727283db402dec6f666f1b55a.)
Bug: 18529433
Change-Id: I632e91281884471a362960f1ba30312d2669b8ff
Remount will now remount the vendor partition as well, if it exists.
Sync will also allow you to sync vendor, and will include it by
default if it exists.
Change-Id: Iea1e8212f445e96233438a8d8a9d3266bf3d6557
Signed-off-by: Daniel Rosenberg <drosen@google.com>
When a filesystem is mounted read-only, make the underlying
block device read-only too. This helps prevent an attacker
who is able to change permissions on the files in /dev
(for example, symlink attack) from modifying the block device.
In particular, this change would have stopped the LG Thrill / Optimus
3D rooting exploit
(http://vulnfactory.org/blog/2012/02/26/rooting-the-lg-thrill-optimus-3d/)
as that exploit modified the raw block device corresponding to /system.
This change also makes UID=0 less powerful. Block devices cannot
be made writable again without CAP_SYS_ADMIN, so an escalation
to UID=0 by itself doesn't give full root access.
adb/mount: Prior to mounting something read-write, remove the
read-only restrictions on the underlying block device. This avoids
messing up developer workflows.
Change-Id: I135098a8fe06f327336f045aab0d48ed9de33807
Yabin Cui