Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

1. I logged in as root and installed Apache with yum install httpd
2. Still as root, and inside /var/www/cgi-bin/ I wrote a simple test cgi script 
#!/usr/bin/perl
print "Content-type: text/html\n\n";
print "Hello World!";
3.tested it with 'lynx http://localhost/cgi-bin/1.cgi' and it was ok

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?

The problem started when I needed to use an other version of perl, more up to date than system perl, installed in another users home directory:
so '#!/usr/bin/perl' of the script should point to '#!/home/mytestuser/bin/perl'

4.Again as root I make the change and try 'lynx http://localhost/cgi-bin/1.cgi' once again but I get an interal server error,'permission denied' I've played around with the permissions, even changing the perl's executable ones to chmod a+x+w+r but the nothing changed.

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?

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?
thanks
  • Comment on cgi questions/calling perl binary in non default location

Replies are listed 'Best First'.
Re: cgi questions/calling perl binary in non default location
by scorpio17 (Canon) on Aug 23, 2019 at 18:05 UTC

    The default apache user (i.e., the user that your cgi-bin scripts will run as) is 'apache' on redhat-like systems, and 'www-data' on Debian-like systems (i.e., Ubuntu). There is a setting in one of the apache config files to specify this. I have an old redhat server, and on it the file is /etc/httpd/conf/httpd.conf. On a newer Ubuntu server, the file is /etc/apache2/envvars. Depending on OS and version, it may be slightly different.

    The reason your're seeing an error (and the answer to question #3) is probably because the default 'apache' user does not have permission to read/execute files inside /home/mytestuser. You could fix this by either doing this: 

    chgrp -R apache /home/mytestuser
chmod -R 775 /home/mytestuser

    [download]

    OR - you could edit the apache config files and make mytestuser the default user (the user that apache runs as).

    Either way, scripts inside /var/www/cgi-bin need to have read and execute permission by that user. If you have a group of people doing web development, you could create a "web_dev" group for them to belong to. Then files belonging to that group can be modified by any of the developers.

    So, to answer question #1, I would do this: 

    chown apache:web_dev test.cgi
chmod 770 test.cgi

    [download]

    Question #2: it will run as default user ('apache' - unless you change it in the config file)

[reply]
[d/l]
[select]
Re: cgi questions/calling perl binary in non default location
by dsheroh (Monsignor) on Aug 24, 2019 at 10:08 UTC
    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.

[reply]
[d/l]
[select]
A reply falls below the community's threshold of quality. You may see it by logging in.

Back to Seekers of Perl Wisdom