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
