I want to ask regarding su root -c '/some/foo/command' <<<'somepass'. as we know we can't use string input redirection in shell (not bash) env.

For your information, my box is alpine on WSLv2, so security isn't an issue as it's a windows WSLv2 dev box. The script can't be run with bash, as it's a /etc/profile.d/*.sh scripts, that run before user login and always use shell instead of bash, so I can't change the way it use bash, is there any possibility to pass the password to the input without using a flat file like in bash, or is there anyway to force /etc/profile.d/*.sh scripts run with bash instead of normal shell script interpreter?

any pointer to this appreciated. Thank you! NB: if you think this should be on serverfault, please let me know, as my opinion this should be on scripting side, so the most suitable site is stackoverflow. Thank you.

CodePudding user response：

If you are just asking how to do a herestring when the shell you are using does not support herestrings, then:

su root -c '/some/foo/command' << EOF
somepass
EOF

I can't write this response without at least remarking that passing a password this way is not secure.

CodePudding user response：

There are several possibilities, if I understand your question correctly.

Option 1: Use wsl.exe to run as root without password

First, as a bit of a "hackaround" on WSL, there's probably no reason to need to enter the password in the first place. As long as you have WSL's Windows Interop feature enabled (which it is by default), you can simply call the wsl.exe command from within WSL to elevate the user to root using something like:

wsl.exe ~ -u root -e /some/foo/command

No password is needed in this case. As you said, since this is WSL, the security model of the Windows user is what is enforced.

This form assumes, of course, that the script:

1. Has a shebang pointing to the correct shell/interpreter
2. Is set with the executable bit

If there's no shebang line, and you need to specify the shell or interpreter which should run the script, you can use something like:

wsl.exe ~ -u root -e bash -lic /some/foo/command

Explanation of the arguments:

• ~ is good practice with WSL to set a common starting directory of the user's (in this case, root's) home directory. It must be the first argument after the wsl.exe command.

• -u (--user), of course, specifies the user in the WSL distribution to run as

• -e (--exec) is the executable to run in place of, or as, the shell. For instance, wsl.exe -e ps -efH (when nothing else is running) will run just the ps command with no "owning" process/shell.

• bash -l treats it as a login shell, so that your profile is sourced at startup. Without this, you may be missing necessary environment variables or other configuration for your command. However, if you don't need it for that command, leave it off, since not sourcing your profile will likely improve the execution speed.

• bash -i is the same as above, but for "interactive" shells, so that your rc file (e.g. ~/.bashrc) is sourced. Again, leave it off if unneeded, which is likely won't be for a root executed script.

• bash -c is, of course, the command string to run in the shell.

Option 2: Pass the password to sudo

Per this Super User answer, use sudo -S to accept the password from standard input.

(Possible) Option 3: expect

I was thinking about this last night in a similar context, and I believe expect can be used for this type of situation. I haven't had a chance to try it out yet for my use-case. For your case, of course, the first two options are almost certainly easier and more robust.

But keep expect in your toolbelt for other possible scenarios like this.