SELinux: Unit system-manager.target not found
#115
Comments
|
Could be related to SELinux. |
|
Enabling permissive mode lets it work. This seems to be SELinux related. Probably easier to debug further by installing Fedora which has SELinux by default. |
soupglasses
changed the title
Unit system-manager.target not found on openSUSE Tumbleweed.Unit system-manager.target not found
|
The empty target is normal, it's just a synchronisation point. I'm not very familiart with selinux, and haven't tested system-manager with it. I'm happy to review patches to improve the interaction. |
|
Yeah it being empty was a red herring and the actual issue is SELinux refusing SystemD from reading the files generated by system-manager. I also am not the best at SELinux, but i may look at this at some point soon if someone else doesn't get to it first. |
|
From some experimentation, it seems the double indirection through So the solution would likely be to generate this Any thoughts? @r-vdp |
|
Never mind, it started showing up again even with this change... Back to the drawing board... |
|
Could be a me problem. I seem to have some SELinux issues outside of just System Manager now. Gonna reinstall sometime soon to see if a clean environment shows the same problems. |
|
The reason for this indirection is so that we can switch to a new generation atomically, so we cannot just remove it in any case. |
|
So this was partly my fault, However, there is one change needed to be done, and that would be to move the path where we store service files in the nix store to a FHS location so it will properly get labelled. Manual steps to make it work for me right now: This should probably also be done for things like |
|
Also I'm curious why something like linking to the path /nix/var/nix/profiles/system-manager-profiles/system-manager isn't used instead of adding a hidden file in I also need some help figuring out where |
|
The custom path in etc doesn't get labelled correctly and breaks. Linking to Gonna have to think if we should add our own selinux policy here just to get this linking to work. But it still requires the corrected paths inside |
|
So after some more testing, i have found out that there are some fundementals in SELinux i do not understand. We'd need a way to add SELinux support to Nix to label the files correctly when it genereates them. This seems basically out of the water already but i have opened an issue here https://git.lix.systems/lix-project/lix/issues/546 to see if Lix would be interested in this support. However, what makes things extra complicated is that most services has their own custom type, for example: How we will encode this correctly im not sure. We might ship our own SELinux labels based upon f.x. Fedora's, but modify them to target instead Even worse would be that the current SELinux labels would fight, i think there might be some overriding levels we could apply to override things, but I am already way deep into something I am not familiar with. |
|
Hey @soupglasses. I'm unfamiliar with SELinux, but I know it has been researched for Nix already. Unfortunately, it looks like their conclusions were similar to yours. See NixOS/nix#2670 for a thread to pull on. |
|
Yeah. A hacky way to deal with this would be to do something like the following: system-manager.preActivationAssertions.ensureSELinuxLabels = {
enable = true;
script = ''
echo "Relabelling the Nix store..."
/sbin/restorecon -R /nix/store
echo "Done!"
'';
};I however do not recommend this hack to be upstreamed, as relabeling the entire nix store is likely gonna retread a lot of ground and be excessively slow. And to avoid changing the NixOS Add more There is still the question if this should be more explicitly documented somewhere. It's a real hack, but giving the power to each user to add these as they need can be helpful, and documenting at least how to get it functional outside of running permissive mode is some improvement. |
|
I'd be up for hosting the documentation, even if its content is just: "here is the current state of the art / hack". Giving people breadcrumbs is better than nothing. |
Describe the bug
Running on openSUSE Tumbleweed, running a minimal configuration, it errors on
system-manager.target not found. Unsure if this is due to the minimal configuraiton, or openSUSE. Notably the target gets generated empty?Full output:
The text was updated successfully, but these errors were encountered: