The way I see it is that the packages that lives in /bin,/sbin should
call only libraries at the same very level.
Having a fake library that allows selinux to not be loaded can become a
security concern (I didn't give it much thought, but I think you can see
the risk).
So, by my point of view, the solutions that I see are:

1) compile the packages without selinux
2) move all the required libraries to "/" hierarchy.

My preference goes to number 2.

Antonio

Il 11/01/23 22:59, Rainer Weikusat via Dng ha scritto:
> Steve Litt <slitt@???> writes:
>> Rainer Weikusat via Dng said on Wed, 11 Jan 2023 15:43:58 +0000
>>
>>> karl@??? writes:
>>
>>>
>>> Yet, the system cannot boot without
>>> a working libselinux because someone saw it fit to turn that into a
>>> mandatory part of the system. In my opinion, a system where libselinux
>>> cannot ever be used for anything shouldn't fail to boot because it
>>> can't be loaded. My workaround is good enough for me.
>>
>> Is your workaround to install a faux libselinux which says the right
>> things during boot, but performs no actual action? Sounds to me like
>> that would be an excellent, easy to install and use workaround.
>
> My workaround was copying the missing libraries to / using a live system
> I booted from USB :-).
>
> The alternate idea I was thinking about (after
> implementing this just for init) was creating some sort of library which
> loads the real SELinux library via dlopen and fails gracefully when this
> isn't possible (instead of the kernel panic caused by init
> exiting). This would probably need to become a forked selinux library
> package (and may well not be possible at all, although I think it should
> be possible).
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng