|Think about Loose Coupling|
Re: creating a secure environment for perl scripts to runby talexb (Chancellor)
|on Dec 26, 2021 at 12:15 UTC||Need Help??|
I believe these two questions are asking the same thing. The location needs to be outside the directory that your web server has access to, in order to prevent a bad actor from accessing your script using that vector, so you could put it into your ~/bin directory if this is a personal website. You could put it into the /opt directory tree for a less user-dependent location (so, /opt/foobar/bin for example).
I would use crontab. I have a corporate client with about twenty cron jobs running mostly during the day, one every minute, a couple every ten minutes, some every hour, some just daily, and one weekly. In addition, you can define environment variables inside the crontab configuration to define how the scripts behave.
I'm not sure the '*+' is doing what you want. You may want to test that regexp against some actual paths and confirm that it's doing what you want. A replacement could be '[^/]+' which would then check that the RealBin directory was a user's home directory. (Of course, installing to the /opt directory as I've suggested in A1 would require a change to this rule.)
However, I'm not exactly what this script is meant to do -- just check that the environment is clean? How is the output being used? Are you just logging on a looking at the output? Is there going to be a cron job that E-Mails this to you? Are you going to look at the results on a web page? Will the script stop if it's installed in a bad location?
Well, corruption is when a file is overwritten with junk characters. If it's a configuration file, the odds are that a corrupted file will fail to compile, so that may not be an issue. A corrupted file might have any values in it -- perhaps outside the usual 0x20 to 0x7f values.
If someone maliciously changes the configuration, they're probably going to leave it so that it still compiles, but does something that helps them (or hurts you). Unless a bad actor has broken into your web provider's entire system, or stolen your credentials, it's unlikely you need to worry about someone altering your configuration file.
Hope that helps you.