Pull requests

#6 Open

permanent sebooleans feature

Bitbucket cannot automatically merge this request.

The commits that make up this pull request have been removed.

Bitbucket cannot automatically merge this request due to conflicts.

Review the conflicts on the Overview tab. You can then either decline the request or merge it manually on your local system using the following commands:

git checkout seandroid
git remote add hqjiang/external-libselinux https://bitbucket.org/hqjiang/external-libselinux.git
git fetch hqjiang/external-libselinux
git merge --no-ff -m 'Merged in hqjiang/external-libselinux/development (pull request #6)' remotes/hqjiang/external-libselinux/development
  1. Haiqing Jiang

The permanent boolean feature is implemented as following:

1. Utilize the unused parameter "permanent" in security_set_boolean_list; 
2. Add two new APIs in booleans.c: security_set_permanent_boolean and security_reload_permanent_boolean; 
3. Add two options in setsebool toolbox: set permanent sebool and revert permanent sebool; 
4. Embed the reload of permament sebooleans to the API of "selinux_android_reload_policy": the reload of permanent booleans will be right after the reload of policy.
  • Learn about pull requests

Comments (13)

  1. Haiqing Jiang author

    The major issues have been resolved. Actually it's not infinite loops issue. It is uninitialzed buf issue. I have tested the current version codes, it works fine...

  2. Haiqing Jiang author

    I add readx and writex for reading/writing x bytes for data partition file read/write in case of partial read/write. Current source codes which merely read/write to selinuxfs (psedo file system) have no such problem. But my permanent seboolean feature requires to read/write to /data/security/, during which the partial read/write could happen. This is why I add the readx/writex methods and update my source codes. Please help to review the source codes and give me your insightful comments.

  3. William Roberts

    LGTM, The only thing you might want to work on in a future patch is some atomicity of read/write on the pbool file. Any error's writing should cause a rollback operation to occur, like in a database.