Closed mtdcr closed 7 years ago
Thanks for this, Andreas. The host db thing should really not be built into this at all. I am looking for a functional replacement for amttool to use in scripts that operate on lists of nameless IP addresses and all my nodes have the same password, so having to script around the hostdb feature was cumbersome. I installed your branch and it is much closer to what I need. I preferred way that amttool does auth with the env var $AMT_PASSWORD, but now I can get the same thing like:
echo $AMT_PASSWORD | amtctrl 10.0.0.27 status
rix
How about https://github.com/sdague/amt/tree/prompt as a solution?
From a broad view I would like amtctrl to fill the need for a minimalistic tool to perform a narrowly focused task and let the user script the handling of input and output. It should not impose unnecessary constraints that are peripheral to that task, by forcing you to do auth using a particular ad-hoc database scheme. As for prompting, that is not friendly to scripted applications. Looking at how this is handled by various command line apps, I'd use openldap clients as an example, e.g. man (1) ldapsearch. Ldapsearch command line options give you many ways to auth, including: a clear text password entered on the command line, a (protected) password file containing passwords, or prompting interactively for a password. At least for my scripted use, the pipe feature works well. I don't know if a piped password could be visible in the process list, but my script would run on a system with no untrusted users, so that is not necessarily an issue.
Sean, I looked at your "prompt" branch, and if I understand correctly, you are still including the pipe option:
passwd = sys.stdin.readline().rstrip('\r\n')
I didn't figure what else you had changed, but the pipe gives me a way to use it in a script, which is my main concern.
Thanks
Yeh, my intent was to still give the pipe option as well. It's possible to secure that path, but the echo example will make it world readable when it is run. I'd rather not fall back to the prompt, because it defies the expectation that you can run it and it will not block for input.
I put the hostdb into this code when I wrote it because with 4 systems I ended up either remembering things poorly, or embedding it in an export for .bashrc when using amttool. Storing the state seemed nice so that it was just "amtctl os3 status"
Anyway, if this works for you, I'll do some light testing tomorrow and push out a release.
On Tue, 21 Mar 2017 17:44:44 -0700 Sean Dague notifications@github.com wrote:
Yeh, my intent was to still give the pipe option as well. It's possible to secure that path, but the echo example will make it world readable when it is run. I'd rather not fall back to the prompt, because it defies the expectation that you can run it and it will not block for input.
I put the hostdb into this code when I wrote it because with 4 systems I ended up either remembering things poorly, or embedding it in an export for .bashrc when using amttool. Storing the state seemed nice so that it was just "amtctl os3 status"
Anyway, if this works for you, I'll do some light testing tomorrow and push out a release.
Adding the -p parameter is fine, thanks!
Regarding the pipe, a user should of course choose a secure source like a password manager, e.g. http://www.passwordstore.org/.
FWIW, "echo" itself is not problematic, unless invoked as /bin/echo, because it's a shell-builtin (at least in bash, dash and busybox ash). That being said, using echo alone for anything else than an example is pointless anyway, as it offers no benefit over using the prompt directly.
Regards, Andreas
I tested the "prompt" branch with piped password input and it solves my problem. Thank you. rix
Andreas,
Regarding your comment about the use of echo, I am calling amtctrl from a perl script, as
$status = `echo $AMT_PASSWD | amtctrl -p 10.0.0.x status`
Since all of my nodes have the same password, a password database would be overkill.
There are, no doubt, more complicated ways to call an external program and handle stdin and stdout in perl, but is there a better way?
Thank you. rix
Ok, merged into master now, local testing seems to go fine. I'll do a release shortly.
Storing plaintext passwords is insecure. Prompt for a password or read it from a pipe, if no entry was found in hostdb.