[systemd-devel] Is systemd-cryptsetup binary internal?

[Dimitri John Ledkov]

On Mon, 18 Sept 2023, 17:43 Nils Kattenbeck, <nilskemail at gmail.com> wrote:

> > Why was the decision taken to put these into /usr/lib/systemd instead of
>> > /usr/libexec/systemd/?
>>
>> That's a Fedoraism. Why would one put something there?
>>
>> /usr/lib/ is where private arch-dependent package stuff goes. What's
>> the rationale for /usr/libexec/ though?
>>
>
> I am not aware of it being a Fedoraism. It is at least also used/populated
> on an Ubuntu server I use and documented as part of the filesystem
> hierarchy (hier(7)):
> https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html#ftn.idm236091914528
>


On Ubuntu we mostly use multiarch locations for shared libraries i.e.
/usr/lib/(arch triplet) and /usr/libexec/(native only binaries). To allow
us to have additional places for native only and cross only tools. But it
is not set in stone. Many gnome, KDE, dbus things ship their binaries or
daemons or plugins under /usr/libexec. It sort of makes sense as /usr/lib
is confusing when it mixes public libraries, with private libraries and
binaries.

We can move things around in systemd as well, but on grand scheme of things
it is fairly minor tidy up, as neither locations are in default executable
paths. /usr/lib is in library search path, which was recently abused to
attack remote hosts to load unintended libraries at runtime and clear nx
(the recent ssh attack is hallarious and did use systemd to show really fun
stuff). So keeping only public libraries in /usr/lib going forward might be
a good idea.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20230918/a8faf5ef/attachment.htm>