Script As Updater (SAU) is needed if a script file has to make changes to the solidified system. It's required to modify the solidified file and execute unsolidified files. Any script that's configured as an updater, doesn't get the updater privilege in some cases.

Example and explanation:
Script files aren't executed like other executables or binaries. They're run through the interpreter process (binary) that understands the commands or scripting in the file. For example, cmd.exe and explorer.exe are interpreter processes for .bat and .cmd files, and cscript.exe is an interpreter process for .vbs files. Users might not directly see this difference because Windows takes care of it by mapping the script to the necessary interpreter.  

For example, suppose there are three bat files test1.bat, test2.bat and test3.bat created with contents as below:

test1.bat:
echo “11111”

test2.bat:
echo “22222”

test3.bat:
copy /y test1.bat test2.bat

Solidify all files and make test3.bat as an updater. If test3.bat is run using a double-click action or cmd /c test3.bat, the copy action is successful. If it's run from the command prompt as >test3.bat, the copy action fails. 

If you look at the logs generated closely for both the cases: 

When the script is run in the same process
In the example, the script is run directly from the command prompt as >script_name.



The following event is seen in the Solidcore logs:

<WRITE_DENIED  file_name="C:\Users\user_name\Desktop\bat files\test2.bat" pid="9480" process_name="c:\windows\system32\cmd.exe" ppid="2440" parent_process_name="c:\windows\explorer.exe" event_time="1599847976784" event_time_system="Sep 11 2020:18:12:56" is_system_file="false" deny_reason="File-solidified" user_name="DESKTOP\user_name" />

When the script is run from the same process 
ACC doesn't allow the process to modify the solidified file test2.bat, because after there's a user input in a process, the updater permission mustn't be allowed to that process. We can't determine whether it's running a script, or the user is directly giving it a command. So, this kind of execution is blocked because of security concerns. 

When the script is run in a new process
In the example, double-click or execute cmd /c script_name from the command prompt to run the script.



The following event is seen in the Solidcore logs (s3diag.log):

<FILE_MODIFIED  file_name="C:\Users\user_name\Desktop\bat files\test2.bat" pid="3148" process_name="c:\windows\system32\cmd.exe" ppid="2440" parent_process_name="c:\windows\explorer.exe" cksum="da39a3ee5e6b4b0d3255bfef95601890afd80709" cksum256="e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" event_time="1599846761194" event_time_system="Sep 11 2020:17:52:41" file_type="script" is_system_file="false" user_name="DESKTOP\user_name" workflow_id="UPDATER: AUTO_24" />

When the script is run a new process
ACC allows the process to modify the solidified file only in that specific process lifecycle. Double-click and "cmd /c script_name" both spawn a new process to execute the script. This process is granted updater permission until its termination. These permissions aren't passed to the child processes as well unlike the regular updater processes. We get a file modified log as shown in the log above, which contains the workflow ID that's used to modify the solidified file.