Getting Data In
Highlighted

Powershell scripted input

Splunk Employee
Splunk Employee

I have a Powershell script that runs continuously and prints some data to the console. I'd like to configure Splunk to index this data.

I went to Manager » Data inputs » Script » Add New and entered this line in 'Command'

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe "-command "& 'c:\myscript.ps1'""

but in splunkd.log I get this message:

02-02-2010 17:51:35.195 ERROR FrameworkUtils - Incorrect path to script: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe.  Script must be in a bin subdirectory in $SPLUNK_HOME.
02-02-2010 17:51:35.195 ERROR ExecProcessor - Ignoring: "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe "-command "& 'c:\myscript.ps1'""

Why am I not allowed to call powershell?

P.S. I found a workaround for this by having a .bat file inside SPLUNK_HOME\bin\scripts. It contains the command line from above. Then I've created a scripted input pointing to this .bat file.
But it looks much less than optimal having cmd.exe to host powershell.exe and I hope someone has a better solution.

Highlighted

Re: Powershell scripted input

Splunk Employee
Splunk Employee

Have you tried having your powershell.exe scripted input be in a bin subdirectory in $SPLUNK_HOME?

Highlighted

Re: Powershell scripted input

Splunk Employee
Splunk Employee

thanks, V, your suggestion inspired me for another workaround below 😉

0 Karma
Highlighted

Re: Powershell scripted input

Splunk Employee
Splunk Employee

The requirement that people be able to modify files in the appropriate script directories is not a strong security guarantee, but it's more than nothing. If anything we just need better commentary around the feature.

Highlighted

Re: Powershell scripted input

Splunk Employee
Splunk Employee

Anotherway to avoid "wrapping" via BAT is to ensure that the scripts located in the bin directories are automatically associated with the appropriate script engine by the OS (or by Splunk). In Unix, the convention of using #!/path/to/shell does this. In Windows, .bat files are associated with the cmd.exe, and you can create new associations via FTYPE and ASSOC.

In this case, you do not need to wrap your scripts inside of another script, and at the same time, users are limited to only running code that has been explicitly placed in the specified locations (and presumably vetted).

Highlighted

Re: Powershell scripted input

Splunk Employee
Splunk Employee

I've got one more solution that I'm going to use:

Instead of using bat files you can create a .path file:
/apps/myapp/bin/myscript.path that will contain the following:

%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe -command "& {set-executionpolicy Remotesigned; '$SPLUNK_HOME\etc\apps\myapp\bin\myscript.ps1' -myarg1 -myarg2}"

And in inputs.conf write:

[script://$SPLUNK_HOME\etc\apps\myapp\bin\myscript.path]

It worked like a charm.

Update: Recommend using a relative path instead:

[script://.\bin\myscript.path]

View solution in original post

Highlighted

Re: Powershell scripted input

Splunk Employee
Splunk Employee

Splunk does not allow execution of programs outside of designated locations for security reasons. If it was allowed, any user who could create inputs could execute any code as the Splunk account. To control this, any code that a user can run must be explicitly placed in designated locations by someone who is authorized to do so.

Allowing a special case for cmd.exe or powershell.exe would have the same security hole.

Your workaround is perfectly valid, and is the intended one.

0 Karma
Highlighted

Re: Powershell scripted input

Splunk Employee
Splunk Employee

It would be better to configured the script stanza to read as:

[script://.\bin\myscript.path]

as this will make it independent of the name of your app folder.

Highlighted

Re: Powershell scripted input

Splunk Employee
Splunk Employee

Oh, and note that using a relative path doesn't have the security hole, as Splunk will only accept a path from the app's own "bin" directory and below, i.e., it won't use a path containing a ".." component to go up and run something else.