I want to run a sudo command that prompts a GUI for the user to enter their password and get the password back for future use.
running this in a gnome-extention
GLib.spawn_command_line_sync('sudo echo e')
I get the following error
sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper
You should never be storing user passwords for later use or running privileged programs that spawn other programs, but instead prompting each time you need it.
To prompt for a privileged program, you can usually use pkexec in place of sudo. Additionally you should be spawning asynchronously with Gio.Subprocess whenever possible, as a synchronous subprocess will block the main thread of GNOME Shell.
Related
i have a question related to connecting via ssh with "system()" function in perl.
in my perl script i want to connect via ssh to another ip, run a command and return its value or redirect result value to a file.
system ("su - anotherUSer ; ssh someUsername#someIpAddress");
(i change my username so that i am not asked for a password)
when i execute this only line it changes the username correctly but not connects via ssh. In other words, the second part of the system call is not done (or is done but not reflected on the terminal).
If i enter mannualy to the server where this script executes and run this two commands, i can run them without errors.
When i run "exit" command to logout my anotherUser user an error raises:
(ssh: "username"."ip": node name or service name not known)
I also tested it escaping '#' and '.'
system ("su - anotherUSer ; ssh someUsername\#number\.number\.number\.number");
in this case when i run the "exit" command, it askes for the password(Remember that i swiched users so that password could be ommited).
I hope you understand my problem.
Thanks!!!
You're telling the wrong shell to execute ssh.
You spawn a shell and ask it to execute two commands, su and ssh. It first spawns su, which launches another shell. You didn't tell this new shell to do anything, so it waits for input. When it finally exits, the first shell executes the second command, ssh.
Use:
system("su -c 'ssh someUsername#someIpAddress' - anotherUSer");
But that's nasty! Why not just set up a key for the current user instead of becoming anottherUSer to use theirs?
I am running a script in background using fabric. To do that I am using below mentioned function.
def init_db(var):
with cd("%s/scripts" % var):
sudo (" nohup ./init_database.sh &> initdatabase.out &", pty=False)
I have to use pty=False to do it in backgound but this fails as in sudoers file "Defaults requiretty" option is mentioned which does not allow me to run sudo from fabric without pty.
I cannot edit the sudoers file all the time for every server, can anyone please give me some other solution.
Thanks,
Imran Teli
Warning: This is not safe! Do not use this!
Fabric supports giving the sudo password in the shell command:
fab --password=password [...]
However, this means the password may be stored in the shell history, log files and other random places where they could be easily retrieved by anyone having any sort of access to the box.
The safe way to do this is, as you mentioned, setting up sudoers to allow exactly the things you expect the script to do, and nothing else, without a password.
I have a Perl CGI that is supposed to allow a user to select some files from a filesystem, and then send them via Rsync to a remote server. All of the HTML is generated by the Perl script, and I am using query strings and temp files to give the illusion of a stateful transaction. The Rsync part is a separate shell script that is called with the filename as an argument (the script also sends emails and a bunch of other stuff which is why I haven't just moved it into the Perl script). I wanted to use sudo without a password, and I setup sudoers to allow the apache user to run the script without a password and disabled requiretty, but I still get errors in the log about no tty. I tried then using su -c scriptname, but that is failing as well.
TD;DR Is it awful practice to use a Perl CGI script to call a Bash script via sudo, and how are you handling privilege escalation for Perl CGI scripts? Perl 5.10 on Linux 2.6 Kernel.
Relevant Code: (LFILE is a file containing the indexes for the array of all files in the filesystem)
elsif ( $ENV{QUERY_STRING} =~ 'yes' ) {
my #CMDLINE = qw(/bin/su -c /bin/scriptname.sh);
print $q->start_html;
open('TFILE', '<', "/tmp/LFILE");
print'<ul>';
foreach(<TFILE>) {
$FILES[$_] =~ s/\/.*\///g;
print "Running command #CMDLINE $FILES[$_]";
print $q->h1("Sending File: $FILES[$_]") ; `#CMDLINE $FILES[$_]` or print $q->h1("Problem: $?);
However you end up doing this, you have to be careful. You want to minimise the chance of a privilege escalation attack. Bearing that in mind….
sudo is not the only way that a user (or process) can execute code with increased privileges. For this sort of application, I would make use of a program with the setuid bit set.
Write a program which can be run by an appropriately-privileged user (root, in this case, although see the warning below) to carry out the actions which require that privilege. (This may be the script you already have, and refer to in the question.) Make this program as simple as possible, and spend some time making sure it is well-written and appropriately secure.
Set the "setuid bit" on the program by doing something like:
chmod a+x,u+s transfer_file
This means that anyone can execute the program, but that it runs with the privileges of the owner of the program, not just the user of the program.
Call the (privileged) transfer program from the existing (non-privileged) CGI script.
Now, in order to keep required privileges as low as possible, I would strongly avoid carrying out the transfer as root. Instead, create a separate user who has the necessary privileges to do the file transfer, but no more, and make this user the owner of the setuid program. This way, even if the program is open to being exploited, the exploiter can use this user's privileges, not root's.
There are some important "gotchas" in setting up something like this. If you have trouble, ask again on this site.
I'm writing a bash script that requires root access and so what I need to do is write something like
$my_psswd >> sudo some_command parameter1 parameter2
to automate the process. I'm not concerned if this opens up security holes. This is more or less of an example that I can think of. But the problem is that when I initiate sudo anything, it asks for user input which I'm not sure how automate or provide as a variable.
I've tried things like
$my_psswd >1 sudo something
echo $my_psswd | sudo something
but none of this is what I want. Also this has to be a bash script, I can't use a program like expect. Thanks.
You need -S switch for sudo command:
-S The -S (stdin) option causes sudo to read the password from the standard input instead of the terminal device. The password must be followed by a newline character
I recommend against doing this at all. You will be storing your password in plain text which means other people may have access to it. Or it will be visible in process listings, again available to other users.
There are a couple of alternatives to prevent this:
Run the entire script using sudo. Do not use sudo in the script itself but run the entire things with elevated privileges. The downside is off course that your might be executing things with elevated privileges that do not require it but with no more background that's impossible to say.
Better would be to configure your account to execute those specific commands through sudo without providing a password. That way you can execute only the commands that need it with elevated prvileges without the problem of providing a password.
A workaround could be to run sudo -l before calling the script. That way sudo will have an active session and won't prompt for a password. This is only a workaround and would fail if one of the commands takes longer to execute than the configured grace time for sudo. But in small scripts this might be an easy fix.
Try echo $PW | sudo -S cmd
It may work for you.
you are not suppose to use sudo this way, use visudo to specify what commands are allowed to what users, then you don't need to worry about passwords.
Is there any way to pass a password to the linux "su" command? I'm attempting to automate a deployment using sshexec and Ant. As part of that I need to execute the "su" command, but I can find no way to give it a password. The su command does not have the -S switch like sudo. I've tried using the commandResource and input properties on sshexec, but I just get an "su: Sorry" back.
Before anyone thinks I am, I am not storing passwords in files. The script to execute is being generated in memory in Ant based on prompting for a password.
Not an expert at this but you should probably use sudo instead of su. The following thread might help more pass-password-to-su-sudo-ssh