hakurei/acl.go, branch developlow-level userspace tooling for Rosa OShttp://src.rosa.moe/hakurei/atom/acl.go?h=develop2024-09-03T16:20:12Zrename to fortify and restructure2024-09-03T16:20:12ZOphestra Umikercat@ophivana.moe2024-09-03T16:20:12Zurn:sha1:d8f76f3b2594db4687c0203c4f2be8d3e4ef7740
More sandbox features will be added and this will no longer track ego's features and behaviour.
Signed-off-by: Ophestra Umiker <cat@ophivana.moe>
acl: fix memory leak in removeEntry2024-07-15T03:40:29ZOphestra Umikercat@ophivana.moe2024-07-15T03:40:29Zurn:sha1:7d96b0bf350d87463f4c082342d98c54aefe2b51
According to manpage acl_get_qualifier(3) the void * returned by this function could be allocated on the heap.
Signed-off-by: Ophestra Umiker <cat@ophivana.moe>
x11: wrap libxcb ChangeHosts request2024-07-14T09:31:53ZOphestra Umikercat@ophivana.moe2024-07-14T09:31:53Zurn:sha1:518fd54ff3c7fe718f81a995f75913d1fdd6fc31
Even though many pure Go libxcb implementations exist, it is at least as complex and unreadable as libxcb, if not more. Since well known libraries like SDL, qt and gtk uses libxcb, and they somehow understand how to use it, I can only assume these people have read enough code to make sure it's correct enough. Call it wishful thinking. I don't care anymore.
Signed-off-by: Ophestra Umiker <cat@ophivana.moe>
acl: implement acl utils via libacl2024-07-10T15:38:21ZOphestra Umikercat@ophivana.moe2024-07-10T15:38:21Zurn:sha1:2ef29ab52e321104a1ee863f4c1f19948f7da66f
The library is simple and should be easy to port to Go, however correctness matters more in this case and overhead from cgo is negligible for our usage scenario.
Signed-off-by: Ophestra Umiker <cat@ophivana.moe>