I have a program that is going to take a password as input and then do a shell execute to perform a "su" (switch user) command in UNIX. However, I don't know how to pass the password variable to the UNIX su command. The language I have to use for this is pretty limited (UniBasic).
Any ideas?
Well, the best way to do that would be a setuid-root binary that ask for the password then execute whatever command is needed but it requires knowledge you say not to possess. I'd advise in looking at sudo(1) instead.
You could ssh to localhost as another user to execute whatever command you want. Or, use sudo and edit /etc/sudoers such that sudo does not ask for a password. However, there could be security implications.
EDIT: Please let me know why when you vote it down. My answer may not be perfect but at least it works. I do that myself for some licensed software that can only be run under a weird user name.
You do not want to specify the password as a command-line argument. Not so much because of #unwind's answer (scripts could be made private) but because if someone runs a list of processes, you could see the command argument and hence the password in question.
The version of su I have on my Linux server does not support such an option. I checked sudo, but it doesn't either. They want to do the prompting themselves, to ensure it's done in a safe manner and (I guess) to discourage people from putting passwords verbatim in scripts and so on.
You could also look at the 'expect' utility that was designed to script complex user inputs into a programs that weren't flexible enough to receive this input from places other than stdin.
Related
How can I change the user's password over ssh connection (not via browser interface) on the UBNT (Ubiquity Network) device, more specifically airOS8 WA v8.x board?
I want to avoid the ridiculous restriction imposed by their web interface on the password complexity (the only thing they don't require in the password is the unicorn's blood). I don't feel comfortable with someone else telling me what my passwords should look like (for my own well being, of course), so I'd like to change it via ssh connection, where this restriction is not being imposed.
I followed the discussion on their forums, which is just a useless bike-shedding over the opinions if the developers should impose such restrictions (without the switch to turn that off) or not.
I found the way to do this and wanted to share with others, who need to do the same thing.
First, log in to your device over an ssh connection. Then, issue a passwd command to change your password. If you now just reboot your device, the new password won't be saved, so read on.
Next, you need to copy the new password hash to a file named /var/tmp/system.cfg. So, first, type cat /etc/passwd, to see the new password hash, which should look something like this:
ubnt:$1$ssssssss$hhhhhhhhhhhhhhhhhhhhhh:0:0:Administrator:/etc/persistent:/bin/sh
where ssssssss is the Salt and hhhhhhhhhhhhhhhhhhhhhh is the Hash of the new password. We need to copy all that to the /var/tmp/system.cfg file, so type:
vi /var/tmp/system.cfg and in there, find the line that starts with users.1.password= and change it to be like this (press 'I' for Insert operation):
users.1.password=$1$ssssssss$hhhhhhhhhhhhhhhhhhhhhh
where Salt and Hash will be something randomly generated. When you finish changing that line, press Escape key and then save/quit the file (pressing colon, 'w', 'q' and Enter key, like ':wq')
Once you're back in the shell, type save to save this configuration permanently and then type reboot to check if your password survived the reboot process.
That should be it.
Thanks, but much better is to use a hash of default password ubnt, to get it, just run grep users.1.password /var/etc/default.cfg
I am currently working on Swfit. For safe, the op ask me to set password for rsync.
While, as we use Swift, we just set rsync work as server with "/etc/rsync.conf" , then Swift works as the client without password.
So, my question is, if i start the rsync with "secrets file" option, which set the user:password. Then, how to set Swift with the password?
Read the Swift code about the rsync in replicator, i can't find the option to set the password.
Or, Swift doesn't support the function?
Luckly, by reading the source code, i find the way to support rsync with 'secrets file' option:
By adding the '--password-file=/your_passwd_file_path' to rsync order in this two function:
swift/common/db_replicator.py/_rsync_file() and swift/obj/replicator/rsync()
Then, restart your swift, it will work right.
How can you provide the password to ssoconfig.exe -restoresecret as parameter?
I'm trying to use the sysprep scripts from Colin Meade on TechNet
Checked on MSDN and ssoconfig -restoresecret only has <restore file> as a parameter ... no reference to "password"
Yet when I run the command, I get the prompt for a password, along with the password hint!
As described in http://msdn.microsoft.com/en-us/library/aa560589.aspx, the command does not let you restore a secret with a password as a parameter. So it doesn't seem to be viable via the command line.
I don't know what the use-case is in your case, but in general I'm not sure if this would be something you want to automate?
What you can do is automate it yourself by writing a wrapper (e.g. console application) for it. You can do so by sending keystrokes to the command line, there are various examples available here on SO.
In my app I ask users to register using a unique name. The app creates a directory for them with that name that they then can work with, saving files, etc.
I hadn't really thought about screening for other than alpha-numeric for the name. However, I ran across a thread somewhere than said to make sure not to create directory names that match a unix command name.
Is this a legitimate risk? If so, how might one programmatically screen for such an occurrence? I'm also curious how such a scenario might play out to illustrate the problem (exploit?). That last part is academic interest only, of course.
Generally, it doesn't matter(has no obvious security risk). Most softwares, for example shell, search a unix command based on some enviroment variables(like PATH). So even if your created directory matches a unix command like "cd", it can only be used as a parameter to other unix command, like cd cd.
However, if another application search the unix command based on other approaches like searching some directories, it may lead to security breaches.
The only way I can think of that being a risk is if you're going to turn around and process those user names through command-line functions. You would want to be careful to escape the user names anywhere that they could be interpreted as a command...though off the top of my head, with strictly alphanumeric user names, you'd have to go to a lot of trouble to run into such a risk.
If you decided anyway that you wanted to ensure that the username didn't match an application on the path of the creating process, you could shell out from whatever your app environment is, and evaluate the result of which $prospectiveUsername. If it returns anything other than an empty string, you know that the username is an application on the process's path.
NOTE: In the above scenario, make sure you sanitize the username before calling out to the shell command. Otherwise, you do run security risks, if e.g. the user decides to enter her username as "janedoe; rm -rf /".
I want to copy files from local machine to remote server through SCP command. I was able to copy files through Cygwin. Now I want to achieve this thru Qt. How do I invoke 'SCP' command? If I make use of QProcess, then how will I get to know about password prompt?
As fara as I know, you will hit the same issue with scp prompting for the password whichever way you try to call the command (even if you try writing a bash script that calls scp, for instance)
Possible solution I'm aware of includes:
create a public/private key and distribute them so that you do not need to be prompted with the password. An interesting paper on the topic is here
create an expect script and invoke it with QProcess
Require your users to use public keys and your problem is solved: https://hkn.eecs.berkeley.edu/~dhsu/ssh_public_key_howto.html
scp, ssh, sftp, etc. deliberately make it hard to take a password other than directly from the user. Specifically, things like expect will not work. And if they did, they wouldn't be secure.