serviceaccount password on command line

[arthurblake]

I am struggling with the security problems of passing logon credentials in clear text in the xml (under serviceaccount element) and would prefer a way to pass the credentials directly on the command line... (when installing service.)

I saw that issue #19 may address this, but cannot find exact usage information on that. Could you document basic usage of that feature?

[arthurblake]

Looks like from the code, maybe all I have to do is supply /p and then type the password on stdin. Will experiment with that, but still; updating the readme to document this would be nice!

[slide]

Are you thinking something like just an AES encryption?

[arthurblake]

No I wasn't. I was really just thinking about passing the credentials on the command line so they are just around transiently (as opposed to stored in the XML.) That was before I saw there was a /p option, although it's a bit clunky and undocumented.

[slide]

Adding documentation is easy, but what is clunky about it?

[arthurblake]

It's just clunky for me to implement correctly that's all - everything else is fine about it. (I'm coming from the context of wrapping winsw with a nodejs program (See https://github.com/arthurblake/node-windows) that invokes winsw to do what it needs-- it can invoke it in several different ways, and it's clunky for me to have to grab stdin and pass the password in that way as opposed to just passing it as a command line arg, (not impossible, just clunky.) I would prefer if it was implemented like other MS commands (like net use, etc.) where your can pass /u /p right on command line although I can understand others might consider that less secure.

[oleg-nenashev]

I think it's actually and still reasonable for some cases

[waffel]

Interesting. I had also searched for a option to give the login password for the service accont on cmd while installing the service. /p helped me out (but also asked for username and logon behaviour).

It would be nice to have this information in the install guide (or how to get those "hidden" flags on cmd /? or --help does not print out the option).

[vsspt]

Can you please inform me what is the state of this issue?
Is this implemented in the 2.X version?

[nxtn]

The /p argument was added in 1.14 and documented (only) in the installation guide since 2.0.

winsw/doc/installation.md

Lines 54 to 55 in ea6cb80

	The Installer can be also started with the `/p` option.
	In such case it will prompt for an account name and password, which should be used as a service account.

Bear in mind that /p reads password from the keyboard, not from STDIN.

More arguments can be implemented as part of #433.

[HackerBaloo]

I did't like the /p option, I made a little workaround, by writing the service config twice, first one time with password, I use that for installing the service, then I let my installer write the config file again without the password. It works fine for start, stop, status and uninstall

[waffel]

@HackerBaloo I have done the same.

The ugly thing about this solution: You really should ensure to not leave the password for the service account in the configuration file. Then a "hacker" or ugly user can read the password of your service account.
We have managed to get rid of this by limiting read access to the files ... but all of this is a workaround just to not be able to provide the password on install per command line parameter. So for an "automatic" and easy way of installing services, a command-line switch would be helpful.

[billbarni]

I'm having this problem today. When delivering a package I have to make sure to remove the xml file or limit read, or some other absurd stuff. I can't have a password in text laying around.
Please, just give us the ability to use CLI to do everything.

[HackerBaloo]

I'm having this problem today. When delivering a package I have to make sure to remove the xml file or limit read, or some other absurd stuff. I can't have a password in text laying around.
Please, just give us the ability to use CLI to do everything.

If you are prepared to use the development version, I think it is possible already.

[billbarni]

The only thing holding me back in using the 'dev' version, is it's release in Maven/Jenkings Repo.