My application tries to execute roots command "sudo ifup eth0" and "sudo ifdown eth0". But it returned an error "sudo: sorry, you must have a tty to run sudo".
So, it requires a tty to execute the sudo commands. So, I tried to execute the commands by opening tty sessions
gnome-terminal --command="sudo ifdown eth0" &
xterm -e "sudo ifdown eth0" &
then it worked fine. But I am not able to send the command from newly created gnome-terminal or xterm.
i.e., if I close the newly created gnome or xterm windows before they had executed the commands, then the commands were terminated immediately.
Can you give suggestion how to disable the window from closing by the user
or
how to make it invisible to the user?
Note: you can test this by using system-config-network command instead of ifdown and ifup
I would suggest not to use xterm or gnome-terminal to provide a terminal for sudo, but to deal with the "sorry, you must have a tty to run sudo" message directly.
There is a requiretty option in the sudoers file that makes sudo demand a terminal. If this option is unset with !requiretty and the command is executed with the NOPASSWD option sudo should run without the need to open a new terminal window. There are more details in this serverfault post.
That is how sudo is used for instance in cron scripts.
Since requiretty option provides additional security in an environment where sudo is used not only in cron scripts but to let remote users issue commands with elevated privileges, the action of !requiretty can be restricted.
User_Alias LOCAL_USERS = john, mary
Cmnd_Alias NETWORK_SCRIPTS = /sbin/ifup, /sbin/ifdown
Defaults!NETWORK_SCRIPTS !requiretty
LOCAL_USERS ALL = NOPASSWD: NETWORK_SCRIPTS
If you run your code within X session, then you can use gksudo instead of sudo:
gksudo -m "Your message" /command/to/run
It will prompt user for password (if needed) using nice GUI interface. No need to xterm or gnome-terminal.
Effect will be more secure than allowing particular command to run without any password and solution will be more consistent to what users are used to.
In general, sudo or su need to prompt for a password, or programs could escalate their privileges without user intervention. If you application needs to elevate for some purpose, you will need to use an xterm or similar. There are difficulties though in getting the return code back (konsole might need --nofork and gnome-terminal might need --disable-factory, but the options sadly vary by version), and it's not easy to get it right on every system. Most unixes and linux distributions provide xterm, but some old Fedora/RHEL/CentOS provide X without xterm, so it's another dependency to think about.
The command launched by xterm -e sudo -- ... can then do the standard double-fork and setsid. Once the user has entered his password in the xterm, it goes away immediately, but your command runs in the background with elevated privileges. It can connect back to the original program using a socket or fifo to run as a root co-process.
The daemon or disown commands or similar might be useful if you want to wrap an existing application in a double-fork & setsid (eg, xterm -e sudo -- daemon system-config-network or perhaps xterm -e sudo -- bash -c "system-config-network & disown -a").
Related
Certain applications (for example yay) uses sudo to run some commands as root. This means that I have to sit in front of the terminal and wait until I'm prompted by sudo for a password, then enter it manually to make yay continue. I can avoid this by running a command as sudo first (like sudo -v). That way yay can run commands as sudo without it prompting me for a password.
But some times, applications take so long to install that the sudo session times out (15 minutes) and sudo re-prompts me for a password. Since I usually leave my computer or switch to a different workspace while this happens, the sudo password prompt usually times out which is super annoying.
I don't want to disable the sudo timeout altogether, since it's there for a reason. However, when I expect that a command that uses sudo will take a long time, I would like to be able to disable sudo timing out for the current shell only.
Something like:
sudo --disable-timeout
Now I should be able to run sudo in the current shell, without ever having to re-enter my password, or until I run sudo -k.
Is something like this possible, or will I have to write a wrapper script that regularly refreshes the sudo session for me?
Here is one possible workaround. Write a script like this (e.g. sudo-stay-validated.sh):
#!/bin/bash
while true; do
sudo -v
sleep 60
done
Run the script in the terminal where sudo should stay validated:
$ bash sudo-stay-validated.sh
Press Ctrl+Z to place it in the background, then remember to run $ bg to resume the script in the background.
This keeps sudo validated in the current shell until it's closed.
There seems no easy way to do this for the current shell but you can set a timeout globally.
In order to set a different timeout (globally) than the default (=15 min) you can edit /etc/sudoers:
sudo visudo # opens /etc/sudoers for editing
# change the following line:
# Defaults env_reset
# to:
Defaults env_reset,timestamp_timeout=30 # timeout in minutes
Or:
cd /etc/sudoers.d
sudo visudo -f username
Defaults env_reset,timestamp_timeout=30 # timeout in minutes
Special values:
-1: no timeout
0: get prompted every single time
Generally, the sudo timeout is there for a (security) reason. When you (successfully) try to circumvent that timeout, you weaken the security of your system. So, lets have another look on the stated problem: you run a lengthy job, after some time sudo asks for a password and times out. You propose preventing sudo from asking for the password. Alternatively, prevent sudo from timing out. Put:
Defaults passwd_timeout=0
into your sudoers file to let sudo wait until you enter your password. This will prevent your timeout problem but will stall your build until you enter the password. On the plus side, you avoid compromising security.
Alternatively, since you mention yay specifically, there is a command line option for yay which makes it call sudo in the background to prevent it from timing out. From man sway:
--sudoloop
Loop sudo calls in the background to prevent sudo from timing out during long builds.
Well, why not to use screen for this purpose? Connect with ssh, start screen, start your command and de-attach from screen. Then when you ready to check if it your procedure completed then attach again. But even better send an email notification to special email address and your phone will notify you that the job is done (I hope that you have more or less modern cell phone). https://linux.die.net/man/1/screen
I need to remotely start bash scripts that perform sudo tasks, such as chmod and ntpdate and echoing to gpio.
A cron job might be the best solution for some of this, but cron is giving me headaches. I'd like to pass on this venue if I can...
I've confirmed that my scripts work locally (I can ssh into the machine and run them without a hiccup.)
However, If I try to run them remotely like so: (this is within a C++ system call)
ssh user#pc 'bash -s' < /home/user/myScript.sh
Commands with sudo fail.
sudo chmod fails with: no tty present and no askpass program specified
echo to gpio fails with: write error: Device or resource busy
sudo ntpdate fails with: no tty present and no askpass program specified
Can anyone help explain, or help me determine whats happening here?
I'm open to band-aids and different approaches, thanks!
You already found the problem yourself:
sudo chmod fails with: no tty present and no askpass program specified
If you run you shell script via ssh and the script wants to run the command sudo, sudo itself will ask for the users password. But the ssh session is not a tty! How should sudo now prompt for a password and how to get your password?
You can do it if you provide the password in the script ( what makes it very dangerous if someone else can read that script! )
script.sh:
echo "your passwd" | sudo -S
As alternative solution you can run the ssh session with a more privileged user.
ssh privileged_user#pc 'bash -s' < /home/user/myScript.sh
All that comes with some danger. Running all commands from the cript with a more privileged user can also be dangerous!
I have the following bash script to restart the network manager in Debian. The script works as is it should, but not as I would like it to. When the script asks for the sudo password I am able to pass it along using echo, but it displays the password in terminal while the script executes, making it less asthetically pleasing than I would like. Is there anyway to have the script enter the password, but not display the password text while the script calls for the sudo password?
I have tried as many suggestions on Stack Overflow as i could find, well as Stack Exchange before submitting this question.
Script is as follows:
#!/bin/bash
clear
echo "Restarting service Network Manager"
echo""
sleep 1
echo -e "\033[0;31m......................................\033[0m"
echo -e "\033[0;31m......................................\033[0m"
sleep 1
echo""
sudo service network-manager restart
sleep 2
echo <Password>
sleep 2
echo "Service Network Manager Restarted"
sleep 1
echo ""
echo "Relinquishing control of terminal to user..."
sleep 7
clear
Remove the echo <Password> line? I am pretty sure it does nothing other than display the password, as sudo apparently (through an appropriate entry in /etc/sudoers) works without you having to give a password. (What you write to terminal with echo does not get passed to any other process.)
Generally speaking, you can use sudo -S to make sudo expect the password on stdin. But also generally speaking, if you have to hardcode a password in a script, you're doing it wrong in some way.
Is there anyway to have the script enter the password
Putting password in script is not a good idea. First, from security point of view, password may be recovered from script from anyone with access to script. Second, from maintenance view, once you change your password, scripts suddenly stop working and you have to update them all.
Fortunately, as you are already using sudo there is better solution. You can configure sudo to allow running certain command without password, by using NOPASSWD rule in /etc/sudoers.
myuser ALL=(ALL) NOPASSWD: service network-manager restart
See:
How do I run specific sudo commands without a password?
How to run a specific program as root without a password prompt?
Warning: Always edit /etc/sudoers with visudo, never directly. It prevents you from breaking /etc/sudoers. Once you break your /etc/sudoers, you won't be able to use sudo, including using sudo to fix /etc/sudoers.
try this /bin/echo -e "password\n" | sudo apt-get update
or see this Use sudo with password as parameter
I have Linux server (CentOS release 6.4) which is able to process source code sent by users. On the server is a Java application which starts a bash script which will run compilation and execution commands of these source codes in a limited way (time and memory are limited, no Internet, executed by limited user).
The Java program must be always be running, so it can register new job requests.
When started, the Java program works fine, but after some time (talking in days), commands are not executed properly. I get the following error message:
sudo: sorry, you must have a tty to run sudo
the line which is causing that is:
sudo -u codiana $COMMAND &
where $COMMAND is command to execute along with its arguments
After application restart (kill and start again) everything works.
Is there some time limit on Linux which can cause that?
You can comment /etc/sudoers:
#Defaults requiretty
Edit:
man sudoers | grep requiretty -A 5
requiretty If set, sudo will only run when the user is logged in
to a real tty. When this flag is set, sudo can only be
run from a login session and not via other means such
as cron(8) or cgi-bin scripts. This flag is off by
default.
So if this is not desired open /etc/sudoers with you text editor of choice and comment out this line.
I'm writing a QT application which has a shutdown button. I want to shutdown system with this button but when I use the shell command "shutdown -h now" the system asks for password.
I want to shutdown without password.
My QT code is:
QObject *parent;
myProcess = new QProcess(this);
QString command= "sudo shutdown";
QStringList arguments;
arguments << "-h " << "now" ;
myProcess->start(command,arguments);
Ensure that the user running the process is in the sudoers file.
Use visudo to alter the sudoers file and add something like the following:
<username> ALL = NOPASSWD: /sbin/shutdown
hth
Look at going through gksudo/kdesudo for calling reboot, one of those should be on most Linux installations.
They're simple wrappers that will ask the user for their password to confirm elevating privileges to root and, in your case, calling reboot or shutdown.
Just play nice with the rest of the system and let shutdown ask the user for his password.
Instead of calling a shell command you can call reboot directly to halt or reboot the system. See "man 2 reboot". But you will still get a permission error if the user does not have the CAP_SYS_BOOT capability. With sudo or suid binary, as described in the comment above, you will get this capability (and more).
You can also set the CAP_SYS_BOOT capability for your binary with the setcap program or similar. Remember that this will have to be done after each time the program is recompiled, and you have to use sudo to use setcap.