Toward safer GNU C Library tunable handling

Posted Oct 22, 2023 16:03 UTC (Sun) by dezgeg (subscriber, #92243)
In reply to: Toward safer GNU C Library tunable handling by raven667
Parent article: Toward safer GNU C Library tunable handling

Environment variables are annoying because they by default apply to any subprocesses, which can then cause them to break.

Command line would be much preferable, for example for Haskell code compiled with GHC you can pass 'tunables' to the GHC runtime by passing something like '+RTS -M128m -RTS' on the command line. Of course that GHC solution has the problem of in-band signalling.

At least for dynamically linked programs one neat way would be to explicitly invoke the dynamic linker and pass the tunables there, just like it already supports flags like --preload (ie. instead of 'LD_PRELOAD=foo.so /bin/ls' one can do '/lib64/ld-linux-x86-64.so.2 --preload foo.so /bin/ls').

Toward safer GNU C Library tunable handling

Posted Nov 2, 2023 14:20 UTC (Thu) by roblucid (guest, #48964) [Link]

This is NOT a valid criticism, the environment is for user preferences and things needed for their login session like display devices. The inheritance is required, it can allow programs written before a feature like ssh(1) to work correctly, while CLI arg would require enhancement to a mountain of software when adding functionality.

If your program system breaks it is written badly. Just sanitise the environment when you start your fragile application. Set things like PATH, adjust variables if required. Users are allowed to break their session.
When running with effective UID privilege the environment should not be trusted just as any user input needs careful verification.

Requiring every program anyone ever writes to pass through by CLI argument something like terminal type, printing width or display device is ridiculous.
Similarly you don't want low level routines continually opening config files to simulate the process environment.