> Don’t think that launchd is broken, it’s just very… restricted.
It is fair to call launchd "broken", for the simple reason that what
it does isn't accomplishing what it is supposed to do - and that is the
definition of broken.
The only understandable (if misguided) reason for launchd to be so
restrictive with the services it runs would be to harden them, to
implement some policy that services are *not* supposed to know where
their binaries are, they're not supposed to have any environment,
they're not supposed to be able to use any kind of external information.
The idea, I assume, is to make service execution entirely reproducible,
the same way running services via a supervision tree makes it
reproducible because the environment is always the same. It is just
a step too far to include PATH in the list of restricted information.
However, the mere fact that you managed to wrote your getdirname
utility, no matter what unholy voodoo incantations are needed
(_NSGetExecutablePath()? Darwin plz.) is proof that this hardening isn't
working at all. If there's a workaround to the hardening, then it's not
hardening, it's just an inconvenience for users - iow, dogshit UX.
> If one launched a binary under s6-supervise and restricted the
> environment, the supervised process would be in the same situation,
no?
Not quite.
First, if you're installing a software package on the system, and
you're not making all its binaries accessible via a standard location
such as /usr, *and* you're not adding the binaries' location to your
services' PATH, you are not making the software package functional.
Intra-package *and* inter-package dependencies rely on PATH, that's the
way Unix works, and going against that will just annoy everyone. launchd
is doing exactly that and it is annoying you.
Second, a service directory for s6 is inherently more flexible than
what launchd appears to be doing. The supervision tree does not enforce
restrictions itself: the run script is executed with the whole running
environment of the supervision tree, and it is on the run script to
potentially enforce more restrictions, perform all the necessary process
state changes, etc., before exec'ing the final daemon binary. So, the
person who writes the run script has full control on the process state,
and even if the inherited PATH is minimal, it can be modified before
passing control to the daemon.
>The question for the list is about improvements to the code, and potential inclusion in execline suite. It seems like a robust method of finding the path of a binary. So sorry to bring up too much noise with mac stuff.
So.
Do I want to help you work around the braindeadness of launchd? Yes I
do.
Do I want to add Darwin-specific code to execline (or skaware in
general)
just to work around a misdesign? Not enthusiastically or speedily.
Running services should be a cooperative endeavour between the system
and
the application packages. Here is what I wrote on the fediverse about
two
weeks ago, in a slightly different but similar context (it was about
adding more workarounds to supervise auto-backgrounding daemons):
< Reliability can only be achieved when processes work together, and not
< against one another. Processes that actively fight against good
< supervision practices will never be able to work properly with a
< reliable supervision suite.
< You can't fix stupid. You can't fight against stupid. You can't
< accommodate stupid past a certain point. It's not a good use of my
time
< and energy to try going past that point.
And to be fully honest, here launchd is being a bit more stupid than
I'm
willing to accommodate right now.
If I were to add your suggested workaround to skaware, here's what it
would look like:
- Define the abstract functionality that we want. Here, it would be
"Obtain the realpath of the current executable without relying on
argv[0]
or anything else".
- Make sure the functionality is implementable on every Unix-like I
want
to support. You provided implementations for Linux (/proc/self/exe), the
BSDs (sysctl with KERN_PROC_PATHNAME), Darwin (_NSGetExecutablePath(),
and it looks like it only works with dynamically linked binaries, which
I assume are the only supported ones, God why are people still using
that OS). I would need to look for an additional implementation for
at least Solaris.)
- Write sysdeps in skalibs for all the possible implementations.
- Add the functionality to skalibs, with a generic name (you came up
with sagetdirname() and it's not bad, but I'd call it something like
sagetcurexename() to avoid confusion with what dirname() does); and test
it on every supported architecture.
- Finally, maybe add a program to execline that uses the new skalibs
function. (But... if your environment is so restricted, how would you
find the execline binaries in the first place?)
That's doable, and I may do it in a not so far future because the only
real work remaining is to find the Solaris implementation. But as you
can
see, it's a bit more involved than just adding a program to execline, so
it's not going to happen overnight ;)
In the meantime, since you have a solution that works for you, please
keep using it in your software deployments!
Cheers,
--
Laurent
Received on Tue Apr 01 2025 - 02:35:45 CEST