How do I set the PATH variable for all users and processes? I currently only have the PATH set in /etc/profile but this is obviously not loaded when I run a process remotely. I am running SaltStack and the minion process, when called from the master does not have the right path. Is there a way to set the PATH in a single place for all users and processes?
It depends on which distribution you are using.
On debian/ubuntu the default PATH variables are at:
/etc/login.defs
Also, every process has a process that calls it and it will inherit the PATH from that process. So it doesn't make sense to set a global process PATH that is distinct from the user PATH.
Not an answer to your specific question, but try added 'shell: /bin/bash' and 'runas: username' to your cmd state. It will then inherit the default login path for that user.
Related
I'm creating golang app with a proxy server as a pet project, and I want to have the possibility to set himself as a system proxy. Is it possible? And how?
Proxies are often configured through the HTTP_PROXY, HTTPS_PROXY and NO_PROXY environment variables. In Unix-style operating systems, these variables are inherited from the parent process to its child processes.
This being said:
your program can modify its own environment and start other processes as child processes (passing in the _PROXY variables).
your program may modify the shell startup scripts (like .bashrc, .cshrc), and a newly started shell will pick the values up and pass them to newly started processes.
But I am not aware that modifying the environment of other (active) processes is possible.
I'm trying to run a program in Rust using libc as another user.
nix::unistd::setuid(uid).unwrap();
If I fork and exec a process which runs printenv, the environment does not change. How can I reset the environment to the default for a user?
With nix::unistd::execve()'s third argument env, you have full control over the next processes environment. Also see exec(3).
Is there a way for one process (such as an executable or bash script) to elevate the privileges of another, running, process? e.g. If I have a program running as normal user user, is it possible for another process, running as root to elevate the privileges of the first as if it had been run as root originally?
I have seen exploits modify the credential struct of a process to perform this, but I'm not sure if there's a way to do this more legitimately.
Looking further into this, it appears that there is no way to do this without installing a kernel module; essentially a rootkit. The kind of thing I want is demonstrated here.
No, these properties of a process cannot be altered after it starts.
No. The only way to elevate a process’s privileges is by execing a setuid binary (such as /usr/bin/sudo); you can’t do it to an already running process.
You can, however, ask sudo to copy a file to a temporary path, launch your editor with your own privileges on the temporary path, and then copy the result back in place as root:
sudo -e filename
This is possible, but only at Ring 0, using the commit_creds(prepare_creds(0)), which will update the task struct associated with the userland process, setting UID/GUID to 0. This is only possible with code already running in Ring 0, such as a Kernel module/rootkit or kernel exploit. An example of how this may be done is here.
You could start a new process using sudo, but starting a new instance with higher permissions will always result in a new process being created.
It's not possible to grant additional permissions to an already running process.
This is a linux related problem. I have searched around but did not get a good explanation.
It seems to me that both file configure the setup when I log in, but is there any difference? I notice that there seems to be "some rule" in deciding what should go into two different files. For example, if I need to add a specific search path to $PATH, I should do it in ~/.bashrc. But if I decide to change some system setting, like
/sys/class/backlight
or
/sys/devices/cpu/cpu#/online
then I have to do this in /etc/rc.local, otherwise it will not work.
Is it because these configurations can not differ between users?
Thanks.
The difference is in when they are run and who they're running as when run i.e. rc.local is run on a change of run level and it runs as root. bashrc is bash specific and run on a non login shell as a particular user.
You can find a good explanation of rc.local here
The script /etc/rc.local is for use by the system administrator. It is
traditionally executed after all the normal system services are
started, at the end of the process of switching to a multiuser
runlevel. You might use it to start a custom service, for example a
server that's installed in /usr/local. Most installations don't need
/etc/rc.local, it's provided for the minority of cases where it's
needed.
and you can find what you need about bashrc
man bash
When an interactive shell that is not a login shell is started, bash
reads and executes commands from ~/.bashrc, if that
file exists. This may be inhibited by using the --norc option.
The --rcfile file option will force bash to read and
execute commands from file instead of ~/.bashrc.
There's more info on bashrc in this question...
https://superuser.com/questions/49289/what-is-the-bashrc-file
This question was asked by me a month ago, though later I realized that stack overflow is not the best site for this Linux question. Thanks for people who answered this question earlier, but I would like to add some more explanation here.
Basically there are (at least) three stages where a user may change system environment in Linux:
when the system boots; This stage is most appropriate if we fancy permanent system setting, and should be made via /etc/.... For example, in my original question, the backlight, as well as on-line/off-line management of some CPUs can be set in this way, and /etc/rc.local is the right shell script I should edit. By "permanent", it means that this update will affect all users using the system.
when a user logs in; This stage is most appropriate if a user only wants to change his personal Linux environment. Therefore, files under ~/ (or HOME) should be the right place to look for. For example, ~/.profile (historically referred to as ./bash_profile or ~/bash_login) is a shell script run at login time. ~/pam_environment is not a shell script, but useful for setting environmental variables (see Ubunte-official-wiki-environmental_variables for more information).
when a user starts a bash shell; This stage is more restricted, as it only has effects inside a bash shell (as well as its child processes), hence does not affect GUI environment. So if a user is doing most of his job from a shell, then this is an appropriate stage to go for. The shell script related to this stage is ~/.bashrc. For example, environmental variables PATH can be changed here.
Hopefully this summary is more intuitive than technical.
.bashrc runs for each bash session started (i.e. every time you open a shell). It sounds as though you're talking of .bashrc as if it were .bash_profile which is run once per login.
Depending on what kind of setup you're running the rc.local is a legacy construct but, traditionally it was run on the last run level during start up. You can see this link for other related posts talking about rc.local.
If you're on a system running systemd this is usually included by default in the systemd package systemd-backlight.service.
I have been running executables using spawn in nodejs all this while, now when i am trying to use spawn to run ubuntu commands like unset, export etc, they dont seem to work. I guess cause it is looking for executables.
I even tried exec, that does not seem to work too. Any tips?
I have an ubuntu device running node, from the UI i need to set/unset env variables for proxy, e.g. http_proxy and no_proxy. Apart from export what other way can i do it via node? The env variables should be set system wide not just for the current process.
Environment variables only exist in memory and are local to a process. For any running process, only the process itself can make changes to the set of environment variables "belonging" to that process, but those changes will not propagate to existing child or parent processes.
In short: you cannot change an environment variable that will apply to all processes on your system (not even from a regular shell).
You can only set an environment variable so it becomes available for newly created child processes (child processes by default inherit the set of environment variables from their parent), but that's about it.
If you have control over how the processes that require those specific environment variables are started, you could write the value for those variables to a file (from Node) and source that file right before the other processes are started, but it really depends on the actual use case whether this is a usable option.