|The stupid question is the question not asked|
Re: cgi questions/calling perl binary in non default locationby dsheroh (Monsignor)
|on Aug 24, 2019 at 10:08 UTC||Need Help??|
First question: The script is owned by root.Should I change the owner to what (i.e apache?), and what should the correct permissions be?It should be owned by a regular, ordinary user with no special privileges. Your personal account is a decent choice. The important thing about ownership is that is should absolutely not be owned or writable by the user apache runs as (usually apache, httpd, or www-data, depending on where your apache came from). If it is writable by the apache user, then an attacker who manages to compromise the script (or any other code running under cgi on your system) would have the ability to change its contents, potentially then allowing them to steal user credentials or other data, use it as a staging point for further attacks, etc.
For permissions, it needs to be readable and executable by the apache user, but, again, must not be writable by that user. Whether it's readable and executable by the rest of the world is an occasional topic of debate, but, personally, I tend to make my cgi or cgi-equivalent code chmod 755 on the logic that there's little value in preventing local users from running it in a shell on the machine itself when those same users could just open a browser and run it over the web instead.
Second question: When calling the script from the web, what user does it run under given it is owned by root with permissions 755? does it run as root or apache?By default, all code run by apache is run as the same user as the apache worker processes (apache/httpd/www-data).
If you use the apache mod_suexec module, then code run via cgi can be run as a different user. This is mostly useful when you have cgi scripts belonging to multiple people who don't mutually trust each other (e.g., if you're running a web hosting service) so that each person's scripts can have access to that person's data files, without also giving them access to everyone else's files. If you're the only one with access to your server, you probably don't need mod_suexec, nor the additional complexity and potential security implications it can bring.
Third question: If I could picture it then it goes like this : Web-->request-->Apache user-->perl bin of 'mytest' user-->/var/www/cgi-bin/1.cgi-->permission denied Who does not have permission and to what?The actual sequence would be:
web request --> apache --> /var/www/cgi-bin/1.cgi --> look at the shebang (#!) line --> /home/mytestuser/bin/perl
If your cgi script works properly when you have the system perl (/usr/bin/perl) in the shebang line, but breaks when you change the shebang to point to a different location, then it obviously works up to the "look at the shebang line" step. Thus, it must be failing when it tries to invoke /home/mytestuser/bin/perl. There are three primary possibilities for why you'd get a permission denied at this stage:
1) You say that you've set that file to chmod 777 (which is dangerous; change it to chmod 755 - there's no reason that everyone in the world should be able to write to your perl binary) so we know that the apache user can execute the perl binary itself, but the apache user also needs permission to enter the directory containing that binary (controlled by the directory's "execute" permission) before it can reach the file to execute it. Many distributions set user home directories to be accessible only to the owning user by default, so it's likely that this is your problem. If it is, then setting chmod a+x on /home/mytestuser/ and /home/mytestuser/bin/ should take care of it.
2) Some distributions enable AppArmor or SELinux by default and configure them to prohibit execution of files outside of whitelisted locations. The solution in this case would be to either move your custom perl binary to a whitelisted location (perhaps /usr/local/bin) or to whitelist /home/mytestuser/bin/.
3) You may have /home on a separate partition and that partition may be mounted with the noexec option, which is functionally similar to #2. Again, the solution is to either move the file to a location that isn't mounted noexec or to change your mount options for /home.
Note that, in cases 2 or 3, no user would be able to run /home/mytestuser/bin/perl under any circumstances. So the first step in determining what you're dealing with would be to log in as mytestuser (or as root) and run /home/mytestuser/bin/perl -E 'say OK'. If it prints "OK" then you're dealing with case 1. If you get a permission denied error (and /home/mytestuser/bin/perl is chmod 755), then you're dealing with case 2 or 3.