My other idea for the implementation was to prefix match on the filenames and jam the version string on the end of those.
On Mon, Apr 22, 2013 at 3:35 PM, William Roberts <[email protected]>wrote: > > > > On Mon, Apr 22, 2013 at 11:36 AM, Stephen Smalley <[email protected]>wrote: > >> 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/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<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 have a patch for this, didn't upload it yet >> >> 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. >> >> Agreed with the possibility of it getting out of sync. The revision > file stays with the files, so if /data/security/seapp_contexts is loaded > and /spolicy is in use, when you get the version > information of the file, then you use the mapping file that belongs to > it. > > >> 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. >> > Cant delete stuff off of /data > >> >> 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. >> > > Clients would need some sort of a map, which they need to generate, to > make decisions on what policy file to delete. We could keep the build > support for this mapping file, but require an explicit make > sepolicy_revision, this way it can be given to the clients? > > -- > Respectfully, > > William C Roberts > > -- Respectfully, William C Roberts
