I am using exec from child_process in a node application to run some shell commands.
The problem is: I need to have sudo privileges to run some commands and I am not sure how to programmatically respond to the password prompt.
I do not want the application to hang until a password is entered by the user, I want the application to enter a default password and run the commands requiring sudo using said password.
Is this possible? Ideally, I would like to do this without first logging in assu, ie: just run the application and have it work.
Please no additional libraries.
You could set the SUID on the file so that it always runs with the permissions of the file owner or GUID if you want it to run with the permissions of the group. More information can be found here
Related
I am not sure how you would go about elevating NodeJs' permissions on the fly, the only way seems to be to run the whole program as root / admin.
Is there a way to elevate permissions on the fly (preferably dependency free and cross platform) ?
I've tried running a childProcess with sudo prefixed to the linux equivalent command of the node action (writeFile()), but even that didn't work out ...
The concrete problem:
I am trying to write to the hosts file, but I can't without admin privileges - Hence why I tried elevating the privileges.
Well basically i created another user, and i'm tring to open a node project, but i can't use "code ." (i think it's because vscode is installed in the other user, but idk) without having the following error:
~/amq-javascript-2.5.0/node_modules/rhea$ code .
2020/02/12 10:02:20.859002 cmd_run.go:884: WARNING: cannot create user data directory: cannot create "/home/amq-broker/snap/code/24": mkdir /home/amq-broker/snap: permission denied
cannot create user data directory: /home/amq-broker/snap/code/24: Permission denied
I already tryed with sudo, and got this:
~/amq-javascript-2.5.0/node_modules/rhea$ sudo code .
You are trying to start vscode as a super user which is not recommended. If you really want to, you must specify an alternate user data directory using the --user-data-dir argument.
I'm kinda lost here...
I had the same issue. I was able to finally get it to work by running ...
sudo code . --user-data-dir='.'
OR
sudo code --user-data-dir /home/fregie/.config/Code/ doesn't work because it needs to be a new user data directory, one whose permissions are not as restrictive as ~/.config.
This should work for example:
sudo code --user-data-dir /home/fregie/.code-root-user-data
Note that once we reshuffle the configuration directories this will no longer be necessary to explicitly indicate the root user data dir
I created a discord bot and am now attempting to run it off an Ubuntu Machine.
I installed the folders of the bot and NodeJs, here is what I used to install NodeJS:
sudo apt-get install -y nodejs
Then I used cd to select the directory, and started my bot using node index.js
The bot started, however when I went to close the putty and keep it running on the VPS the bot shutdown. Here is what the directory looks like.
I think the problem is that when you start the app in the putty window, that process is linked to the window and gets terminated when that is closed.
To avoid that you can use a host service like screen, tmux, nohup, bg and so on...
If you want to know which is the best, try looking at this question from the askUbuntu Stack Exchange.
The key concept is that you open a new window using the tmux command (or screen, ...), then run your bot like you always do. When you want to leave but keep the process runing, you can detach the session with a key combination, that changes from service to service.
If you want to access that window again, you can run a command that will "restore" your session, like
tmux list-sessions
tmux attach-session -t 0
The NodeJS instance is terminated when putty is closed. You need something to keep the instance alive. Try:
PM2: http://pm2.keymetrics.io/
or,
Forever: https://github.com/foreverjs/forever#readme
Recommended though is to run the node instance as a service that can reboot on startup. Try looking at this:
https://stackoverflow.com/a/29042953/7739392
The shell runs in the foreground. This means any scripts you start there will end once you end your session. A simple solution would be to run your script in the background by adding the & after the call:
node index.js &
A better solution would be to create a service you can ask the service daemon to run for you. However, adding the & should get you what you want for now.
I recommend using one of these two node modules - ForeverJS or PM2. I'll show you how to quickly get started with ForeverJS but PM2 would be very similar.
You can easily install ForeverJS by typing the following in your terminal:
$ npm install forever -g
You may need to use SUDO depending on your user's privileges to get this working properly. It is NOT recommended to use it in production due to the security risks.
Once installed CD to your projects file directory and like you typed 'node index.js' you will do something similar with ForeverJS.
$ forever start index.js
Now when you exit the terminal your NodeJS application will remain as a running process.
I have built a GUI with Node.js that allows a user to run custom binaries, designed for CLI. These binaries are spawned with child_process module. A user is able to write to stdin and read from stdout of those child processes.
Yet, when a binary uses sudo command, a password prompt bypass stdout and is headed for (pseudo-)terminal device, therefore I can't catch it programmatically and ask user for a password with a fancy GUI notification. I am aware, that -S argument allows sudo to expect the password from the standard input, yet I have no control over scripts that are run by a user.
I have found out that the stream object that represents stdin or stdout of a process may have isTTY property that indicates that this process is run in TTY context. I have tried to pass streams created with TTY module to stdio argument of child_process.spawn method without any luck.
I tried to use pty.js project (https://github.com/chjj/pty.js/) that actually solves the problem, but for some reasons I can't rely on 3rd party libraries. I try to figure out the way pty.js redirects sudo prompts to stdin, and it seems they use custom C code to emulate PTY (https://github.com/chjj/pty.js/blob/master/src/unix/pty.cc). I am concerned with a comment in one of source files, that states that ‘<...> with vanilla node, it's impossible to spawn a child process that has the stdin and stdout fd's be isatty <...>’. Is that true?
Right now I use a workaround that requires user to elevate privileges to my GUI process so it can spawn children that may use sudo, but I'm not satisfied with this hack. According to manual (http://linux.die.net/man/8/sudo), there is a way to specify helper program to handle password prompt by setting SUDO_ASKPASS environment variable, but I wasn't able to find an example of such an application.
So I'd like to know if there is a common practice to overcome my problem or should I give up and just keep on with getting root privileges preliminary.
I'm writing a command-line program in Node (though will switch if another lang makes this easier) and it stores user data in an encrypted file. I want the user to give her password once during a desktop/ssh session and have it remembered until she logs out.
Presumably my script cannot modify environment variables so that they persist between invocations. How do programs like Keychain and sudo remember your password, and make sure to forget it on logout?
Sudo runs with setuid and is owned by root. So any user that runs sudo will actually be running sudo as the root user. From there, sudo (as root, on behalf of the user) checks the sudoers file (which is only readable by root) to see if the user is allowed to run sudo and what they can do. If the user isn't in the sudoers file, then sudo exits and logs the attempt. If the user is in the sudoers file, sudo asks for the user's password and checks it against what's in the shadow file (also only readable by root). If it matches, sudo will record the access time in another file only readable by root and then execute the command. Subsequent runs of sudo by that user within the timeout period don't prompt for a password, because sudo can check the time of its last record. Sudo does not remember the user's password.
The key point is that, no matter what user runs it, sudo always runs as root and therefore can access files that only root can access.
Your application could mimic this behavior, I suppose, using a special user and a cache that is only permission-ed to that user. It is important that you do not persist passwords. Ever.
Another method that applications use, for example TrueCrypt, is to store the password in memory. This method only works for applications (like TrueCrypt or even the operating system) that are always running. As soon as the application closes, the "saved" password is lost. This technique is mostly secure.
Hope this helps!