On 04/22/2013 12:02 PM, William Roberts wrote:
Support for building a revision mapping file with policy builds has been
submitted for review at:
https://bitbucket.org/seandroid/external-sepolicy/pull-request/14/initial-support-for-revision-mapping-file/diff
https://bitbucket.org/seandroid/build/pull-request/2/add-sepolicy_version-to-product_packages/diff
The idea is to provide the ability to version the policy files without
having to embed the version number into the files themselves.
Possible uses are by updating clients that want to apply a policy. They may
not want to apply the policy if the ramdisk is a higher version. Also, when
a FOTA occurs, the ramdisk version may be higher than the one on /data, so
logic in the choosing of which policy to load could be added to init, etc.
Example code on how we can canonicalize the strings are in that code. See
the pull requests for links to the sample code.
Can we simply export the paths to the currently loaded policy files to
the client and let it compute the hashes itself for identification and
comparison purposes?
I'm hesitant to introduce a separate revision file (prone to getting out
of sync with the actual files, particularly for the /data/security files
and for the /system/etc/security/mac_permissions.xml file which may be
updated separately from the boot image), and I don't know how we would
manage a global revision number that spans all of the files.
Not sure about your FOTA example. If the FOTA is intended to
override/supplant prior policy updates applied using /data/security,
then it should likely explicitly remove the /data/security files.
If you truly need version strings, consider using strverscmp(3) or
similar instead to compare them. strverscmp(3) is a GNU extension so
likely not in bionic but can at least serve as a reference. But I'd
rather avoid any kind of global revision number scheme and just let the
clients use the hashes for identification and comparison purposes. Then
they can decide what is "newer" and what is "older" based on their own
mappings.
--
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.
