Rework SELinux labeling more#397
Conversation
|
Skipping CI for Draft Pull Request. |
943f601 to
d4f4311
Compare
560e6b4 to
0cbe32e
Compare
|
Ah OK right,
We have more forcible labeling to do here. Conceptually this one should be ostree side probably. |
0cbe32e to
8a9cd4a
Compare
|
Ohh yeah, looking at the warning output there's quite a bit of work in ostree to handle this. Updated ostreedev/ostree#2804 (comment) Maybe what we need here for all of that is just a single pass "relabel everything that isn't a deployment with Although
That one should have worked with this. But not sure about blocking on that. |
2362ace to
9ba1f47
Compare
|
OK yeah, I'm going to have to set up a dev/test environment for this "install from host with selinux=0" case, but...I think this latest push should get us a lot closer to working in that path. |
0f914c1 to
0a5f152
Compare
First, in the install code, acquire a proper policy object. Add helpers for writing files/directories that take a policy object and operate *solely* using fd-relative operations and don't fork off helper processes. This is a notable cleanup because we don't need to juggle absolute file paths *and* fds, which avoids a lot of confusion. Our usage of a wrapper for the cap-std-ext atomic write API for generating files ensures that if the file is present, it will always have the correct label without any race conditions. Change the one place we now call `chcon` as a helper process to be an explicit recursive selinux relabeling. In the future we should switch to using a direct API instead of forking off `/usr/bin/chcon` - then everything would be fd-relative. Signed-off-by: Colin Walters <walters@verbum.org>
0a5f152 to
28e5bed
Compare
|
OK cool! Now we're just down to
Which should be pretty tractable to fix in ostree. (In practice it's not really relevant I think because policy isn't loaded until post-switchroot) |
First, in the install code, acquire a proper policy object.
Add helpers for writing files/directories that take a policy object and operate solely using fd-relative operations and don't fork off helper processes.
This is a notable cleanup because we don't need to juggle absolute file paths and fds, which avoids a lot of confusion. Our usage of a wrapper for the cap-std-ext atomic write API for generating files ensures that if the file is present, it will always have the correct label without any race conditions.
Change the one place we now call
chconas a helper process to be an explicit recursive selinux relabeling. In the future we should switch to using a direct API instead of forking off/usr/bin/chcon- then everything would be fd-relative.