This won’t work. This is a per-user location, not system wide.
You don’t need to make a copy of the original txt file to do this, you can just use relevance to build the BAT file within a “create file” command.
That is definitely not intended. You want to exclude all network shares from scanning ideally.
If someone does actually want to go down this path, then it seems like this is the best way to do it on Windows/Linux: https://github.com/logpresso/CVE-2021-44228-Scanner (from @Mario 's link above)
This is my preference, especially because we might not be done with Log4J CVEs and we might have to do this all over again with
log4j-core-2.17.0.jar or similar in the future. I feel like if you already going to mess with things in weird ways, then “patching” it forward is better than removing things.
That said, using the environment variable, the logpresso scan and fix utility, and the replacing of the JAR files could all be done together. You don’t technically have to pick and choose which you do.
That said, the fix of removing the class file that the logpresso scan and fix utility does is not reversible as easily as renaming the affected JAR to something like JAR.20211215.backup and placing the new JAR in it’s place. I like the idea that just swapping out the JAR file for the fixed version is a much more easily reversible operation for either the application owner or for a bigfix operator.
The newest version of the script on github actually accounts for this now.
Oh damn, I definitely want this to be for everything, not interactive shells which are actually much less likely to be an issue. Things running as services are the most likely to be a problem. This is what I was worried about. It does seem like
/etc/environment would be the right place if it exists and is used on the platform, but then annoying that other platforms have other locations.
If someone has example commands to address this for different OSes as far as setting env vars for system services, that would be extremely helpful.