Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

cgi questions/calling perl binary in non default location

by Anonymous Monk
on Aug 23, 2019 at 16:41 UTC ( #11104910=perlquestion: print w/replies, xml ) Need Help??

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

    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

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

Re: cgi questions/calling perl binary in non default location
by dsheroh (Prior) 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.

Re: cgi questions/calling perl binary in non default location
by Anonymous Monk on Aug 24, 2019 at 02:18 UTC
    Access Control Lists (ACLs), available in nearly every Linux/Unix filesystem (with a corresponding facility in Windows) are a simple and reliable way to give the necessary (read only) access to the Apache Server user. Groups are often used to give a development team read/write access to the target directories but the Apache user should have read-only. ACLs can easily arrange this.

      When you say "Access Control Lists (ACLs), available in nearly every Linux/Unix filesystem", do you mean file permissions? POSIX Unix does not really have ACLs beyond the very simplistic concept of "user, group, other" and "read, write, execute". If you find where "nearly every Linux/Unix filesystem" has ACLs, please tell us the manpages of that.

      What Windows ( NT and descendants ) has as ACLs is vastly more flexible for regulating access to resources.

      If you really meant file permissions, use the name "file permissions", and consider actually showing the setup and commands to achieve that setup.

      Maybe some link or sample code or configuration would amplify exactly how your suggestion addresses the OP.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://11104910]
Approved by marto
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (3)
As of 2019-09-22 10:43 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    The room is dark, and your next move is ...












    Results (273 votes). Check out past polls.

    Notices?