--snip-- >> >>> > 2. The policy.X's binary representation and SELinux kernel role_datum_t >>> > structure don't have to be changed, so the max version number for >>> policy.X >>> > won't have to be bumped. >>> > >>> > But it may be desirable to bump the max module version number. >>> > > > Write flavor flag and roles ebitmap into a pp file and read them out unconditionally, this would only run into problem only under one condition, that libsepol/checkpolicy are upgraded with this patchset but the pp files are built before the upgrade took place, which I think could be easily fixed by re-building all pp files by the upgraded libsepol/checkpolicy. > > So I think we don't have to bump MOD_POLICYDB_VERSION_MAX higher. > > Am I right? > > BTW, how do we trigger a pp downgrade? Anything like OUTPUT_POLICY or policy-version to trigger policy downgrade? > > Thanks, > Harry > There isn't a tool that can force a policy module downgrade, but it can be done programmatically, so it should be supported. Additionally, it shouldn't require that modules be rebuilt if the toolchain is updated. So please add a new module version and check that before reading/writing the new role attribute information. Aside from that, I've reviewed this patchset and everything looks reasonable. I still want to test this a little more, but assuming I don't see any any issues with a little more testing, and pending a fix for a module version bump, I'm fine with merging this. - Steve -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
