Default env vars for specific applications

xtf · 2017-06-21 13:45:00

Is it possible to intercept default program launching and to start them with specific environment variables?

Practical usecase:
To start every application in ~/.local/share/steam/steamapps with DRI_PRIME=1
instead of manually setting "DRI_PRIME=1 %command%" for each in the properties.

Ether way by checking the path or a whitelist.

It will probably be a problem because steam starts/forks the applications.

Trilby · 2017-06-21 13:49:26

I'm not sure I fully understand this:

xtf wrote:

It will probably be a problem because steam starts/forks the applications.

Environment variables are inherited. So if steam is calling those other programs then there is no need to set the environment variable for each of them - you only need to set it for steam and any child processes will inherit that value.

xtf · 2017-06-27 09:51:21

I thought there would be a possibility to launch programs by a whitelist with env vars.

But rethinking the unix concept, it is not possible, there has to be a delegated daemon which starts the programs, which inhere steam have to know about it.

Or would it be possible to create a "run interceptor", that intercepts forking and runs it under itself

Trilby · 2017-06-27 10:22:35

I still really have no idea what you are talking about. Please describe exactly what you want, and how what you currently have deviates from what you want. In your first post you referred to a generic %command% in some "properties". What are the commands you want to run with DRI_PRIME=1? How do you (normally) run them? What are the properties you are talking about?

What do you want this "interceptor" to intercept? Intercepting something implies a chain from A to B that you want to put the interceptor in the middle of. What are A and B?

You likely can, as you can just put a new program/script higher in your path with the same name. For example, if you want every attempt to run firefox to actually run a script you made (that may itself run firefox with some added flags or environment variables) then you could create a script named "firefox" located in a directory that is prepended to your PATH.

xtf · 2017-06-27 12:47:39

To start programs independently of the forking application with params.

To pass through optimizations wherever it was started from.

The whitelist ruleset could be shared among other distros, to start applications with params/optimizations.

Like amd/nvidia drivers on windows that have a rulesets for programs.

Lone_Wolf · 2017-06-27 13:11:13

xtf wrote:

To start programs independently of the forking application with params.

Please clarify what you mean by "forking application" and which type(s) of programs.

Trilby · 2017-06-27 13:33:17

I'm not sure if there is a language barrier here, but you really didn't answer any of my questions - at least not in a way I can understand. And judging from Lone_Wolf's similar request for clarification, you are likely going to need to be much more clear on what you need if you hope to find help here.

xtf · 2017-06-27 14:10:29

A parent process forks to child processes, which get the params of the parent process. So far so clear.

The parent process is unaware of any ruleset, therefore a parent parent (grandparents?) which is aware of it must deny forking of specific processes (intercept the forking) by this whitelist and fork() it itself with the parameters of the ruleset.

It would capsule the process and prohibits forking and forks for it itself.

Last edited by xtf (2017-06-27 14:12:25)

Trilby · 2017-06-27 14:24:45

First, this is not specific: what are these hypothetical parents and grandparents? Give specific concrete examples.

However, I think I may see what you are getting at - and if I am correct this is completely an XY problem. I'm guessing that steam is the "parent" which forks individual steam apps (children). The one thing you have never specified that I am not taking a wild guess about is that you want to launch some steam apps with DRI_PRIME=1 while others are not launched with that variable set. Is this correct?

If this is your goal, ask for help with that. You seem stuck on this goal of creating something new (the grandparent) that would run steam, and intercept steam's attempts to fork other processes and conditionally change the environment of the forked process. This is not possible (or certainly not practical, you'd likely have to patch the kernel and/or libc). But while the method you *think* would solve your problem is not viable that does not mean your problem can't be solved. You just need to tell us what the actual problem is - and it's taken me until post #9 to have a guess about what that problem is. I'm now fairly confident in my guess - but I really shouldn't have to guess.

While I don't use steam, reading the wiki page indicates that you can enter a command string which will be passed to bash. If that's the case, you can just prepend the name of your own script to that command string, so steam passes every command to your script. Your script can then check your whitelist - something like the following:

#!/bin/bash
# mysteamlauncher

[[ grep -q "$1" /path/to/my/needs_prime_list.txt ]] && export DRI_PRIME=1

$@

needs_prime_list.txt would just list the app names that need the environment variable. This also assumes that %command% is the first parameter passed to the script from the steam launch options (e.g. steam launch options = `mysteamlauncher %command% ...`)

seth · 2017-06-27 14:37:10

He wants to click "SuperSillyGame™" and when the binary is loaded, have it figure that it resides in /some/path and then inject DRI_PRIME=1 into the process.

You could globally LD_PRELOAD a library that checks /proc/$PID/cmdline and does the desired setenv.
Notice that this only impacts dynamically linked ELF binaries, not scripts and not statically linked ELF binaries.

Another way would be to replace ld.so, but I SEVERELY DISCOURAGE SUCH APPROACH and actually only mention it, because you might stumble across it when googling this. It's easy to screw this and then have wide impact.

Finally, if "default program launching" indeed refers to some particular GUI click-a-run, those tend to pass commands to /bin/sh, so instead /bin/sh being a symlink to (likely) bash, you could symlink it to some "mightyinterceptor" script that inspects the parameters, export DRI_PRIME accordingly and pass the parameters to the actual shell (/bin/bash)
That however heavily relies on the tool you actually want to impact.

Trilby · 2017-06-27 14:41:49

Seth, see my edit which took the last approach. I'm pretty sure he's referring to steam apps for which steam constructs a command line from user customizable input and passes it to bash. If that's the case, the intercept could just be a user-defined shell script.

xtf · 2017-06-27 14:49:49

It would be portable parameters, not specific for "SuperSillyGame™". I used it only as example. Like I said about win graphic driver program specific optimizations.

...But, both answers (#9 and 10) solve my question.

Thanks for the patience

Last edited by xtf (2017-06-27 14:52:22)

Arch Linux

#1 2017-06-21 13:45:00

Default env vars for specific applications

#2 2017-06-21 13:49:26

Re: Default env vars for specific applications

#3 2017-06-27 09:51:21

Re: Default env vars for specific applications

#4 2017-06-27 10:22:35

Re: Default env vars for specific applications

#5 2017-06-27 12:47:39

Re: Default env vars for specific applications

#6 2017-06-27 13:11:13

Re: Default env vars for specific applications

#7 2017-06-27 13:33:17

Re: Default env vars for specific applications

#8 2017-06-27 14:10:29

Re: Default env vars for specific applications

#9 2017-06-27 14:24:45

Re: Default env vars for specific applications

#10 2017-06-27 14:37:10

Re: Default env vars for specific applications

#11 2017-06-27 14:41:49

Re: Default env vars for specific applications

#12 2017-06-27 14:49:49

Re: Default env vars for specific applications

Board footer