On 08/23/2013 03:16 PM, William Roberts wrote: > Thoughts on versioning: > > So a problem exists where an ota, or userdata update can partially update > the files. Also, an OTA can come in that contains a newer policy then > userdata. So assuming that userdata is the newest, is not always feasible. > Time stamping on release servers, drift, etc, make using a time stamp not > feasible. > > Initially, I thought the client setting policy in data could just wake up > on boot, check against a list of hashes and versions internally, and remove > the stale ones from userdata, reboot, and viola, your on the OTA files (or > invoke it via the setprop). > > This would require the update agent to know which is older and newer, > perhaps time stamp on the device, or something, but those could be wrong > too. Essentially, it needs a cohesive way to know what version it is, so > the system can apply the proper policy. > > Their is essentially two issues here: > 1. How do we keep files from being partially updated incorrectly > 2. How do we know which version is the correct one to apply > > For issue one, Josh suggested a db and then a zip. He initially just though > of data, however the larger takeaway is perhaps a container of some sort is > a good way to keep the policies as a cohesive unit (solving number 1) for > both ramdisk and data.Not sure what the best container format would be, > offhand. > > Issue 2, we just need a way to know that this policy version is higher, > please use it instead. Updating agents, places policy is reloaded, whatever > may want to make use of this. So having it as a part of the core container > (bundle) of policy files would be nice as well as an interface for > extracting them, etc. Then the larger issue is just properly creating the > version number. > > Just my 2 cents, and is not meant to be the direction we have to go, but > rather get a good discussion on how we can solve these issues together.
If we go the signed zip route, let's use a whole-file signature (as used by OTA updates) please. Less prone to the recent APK signature nonsense. Do we need to preserve the existing policy bundle format introduced in 4.3 or is that something we can eliminate in favor of just a signed zip file? If I understand correctly, you want to avoid having to take the policy bundle / zip and expanding it out on the filesystem as is presently done by the SELinuxPolicyInstallReceiver. Instead, you want all code that loads policy files to directly open the bundle/zip, validate it, and extract whatever files it needs from within into memory. Is that right? And if there is one under /data/security, you want to open both, compare their version numbers (stored within the bundle/zip), and then decide which one to use? -- This message was distributed to subscribers of the seandroid-list mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe seandroid-list" without quotes as the message.
