semanage...set_local(3)
π semanage_bool_set_active β the Libsemanage API doc, but make it make sense π
okay bestie, so you know how we're poking at libsemanage? This is one of those pages from the Libsemanage API documentation manual, and it's literally just one function. Sit down, hydrate, let's go π«Ά
β¨ NAME β¨
semanage_bool_set_active β update an existing SELinux boolean in the currently active policy
Like. That's it. That's the whole job. You hand it a boolean that already exists and you give it a glow-up β¨
π SYNOPSIS π
#include <semanage/booleans_active.h>
extern int semanage_bool_set_active (
semanage_handle_t *handle,
const semanage_bool_key_t *key,
const semanage_bool_t *data);
three args, no drama, iconic signature honestly π
πΈ DESCRIPTION πΈ
π¦ Behavior
So here's the tea: the set function will fail if no matching key is found in the local store. No key, no vibes, no update. periodt.
Otherwise? The provided object replaces the current one. Out with the old, in with the new π₯
And then β and this is the main character moment β when semanage_commit(3) is invoked, the changes get written permanently into the local store, and they get loaded into policy. So like, the change doesn't really land until commit. It's giving "texting him back but not hitting send yet" π
Also important: the validity of the object being added is checked at commit time. Not now. Later. At commit. Just so you know π«Ά
π§ Parameters
handleβ tracks persistent state across all your semanage calls, and it's also the one doing the error reporting. Basically the group chat admin.keyβ identifies the data object that's gonna be written into the store. It knows who we're talking about.dataβ the actual object getting written into the store.
And a lil detail that matters: the key and the data are properties of the caller. They are not stored or modified internally. So like, they're yours, semanage is just borrowing them, no take-backs, no edits. β¨
β Requirements
This function requires a semanage connection to be established β see semanage_connect(3) β and it must be executed in a transaction β see semanage_begin_transaction(3).
no connection + no transaction = no function. it's a vibe check and you will not pass it π
π RETURN VALUE π
If it goes wrong? -1 comes back, and the semanage error callback gets invoked, describing the error. So you won't be left guessing, bestie, it will tell you π
Otherwise 0 is returned. Zero. Perfect. Slay. π
π SEE ALSO π
semanage_handle_create(3)semanage_begin_transaction(3)semanage_connect(3)semanage_commit(3)
go read those, they're the prerequisites, iykyk π§
okay that's the whole page!! this little masterpiece was written by ivg2@cornell.edu on 4 January 2006 β yes bestie, 2006, it's vintage, it's archival, it's lowkey a piece of history and it still ate π go commit your transaction π«Άβ¨
π¦ where this page comes from
- centos-stream 10: libsemanage-devel 3.11-3.el10 Β· LGPL-2.1-or-later
- debian trixie: libsemanage-dev 3.8.1-1 Β· LGPL-2.1-or-later
- fedora 43: libsemanage-devel 3.9-4.fc43 Β· LGPL-2.1-or-later
- fedora 43: libsemanage-devel 3.9-4.fc43 Β· LGPL-2.1-or-later
- fedora 44: libsemanage-devel 3.10-1.fc44 Β· LGPL-2.1-or-later
- fedora 44: libsemanage-devel 3.10-1.fc44 Β· LGPL-2.1-or-later
- fedora 44: libsemanage-devel 3.11-1.fc44 Β· LGPL-2.1-or-later
- fedora 44: libsemanage-devel 3.11-1.fc44 Β· LGPL-2.1-or-later
- nixos 26.05: libsemanage 3.10
- nixpkgs unstable: libsemanage 3.11
- opensuse-leap 16.0: libsemanage-devel 3.8.1-160000.3.1 Β· LGPL-2.1-or-later
- opensuse-leap 16.0: libsemanage-devel 3.8.1-160000.3.1 Β· LGPL-2.1-or-later
- opensuse-leap 16.0: libsemanage-devel 3.8.1-160000.3.1 Β· LGPL-2.1-or-later
- opensuse-leap 16.0: libsemanage-devel 3.8.1-160000.3.1 Β· LGPL-2.1-or-later
- ubuntu questing: libsemanage-dev 3.8.1-1
- ubuntu resolute: libsemanage-dev 3.9-1build1 Β· LGPL-2.1-or-later
- ubuntu stonking: libsemanage-dev 3.11-1 Β· LGPL-2.1-or-later
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms