Results 1 to 10 of 10
  1. #1

    Question Any point to suPHP on a non-shared dedi? [plus other questions]

    Hello.

    Working on my first dedi. Went to transfer one of my sites, found that PHP could not write to the directory without permissions changed to 0777. It's my understanding that in general this is something that should be avoided. I remember one of my old hosts (Hostgator) installing PHPSuexec, and it allowed PHP to run as a user that avoided that whole issue.

    I couldn't find PHPsuexec per se, but I did find this article with that in the title, explaining how to install and configure suPHP, and it used PHPsuexec in the title:

    http://alain.knaff.lu/howto/PhpSuexec/

    1) Are suPHP and PHPsuexec referring to the same thing?

    2) The server is a dedi, I don't share it with anyone. I am running virtual hosts, but they are all running under the same user atm. Is PHPsuexec what I should be looking at? Or do I simply have something misconfigured somewhere? The user that the server is running under is the owner of the folders, but it is my understanding that PHP doesn't run as that user. PHPsuexec (or suPHP) changes that, right?

    3) Since I am the only user on the server, is there a reason I would want to set up individual users for each virtual server?

    4) Are there any good recent tutorials on getting mod_security installed and running? The one in the tutorials subforum here is over 2 years old. Is the info in there still relevant?

    5) Are there any good tutorials or quick start guides for setting up and securing a dedi?

    Specs of my box, in case it matters:
    CentOS Linux 5.2
    Kernel: Linux 2.6.18-92.1.10.el5 on i686
    Apache version 2.2.3
    MySQL version 5.0.45
    PHP Version 5.1.6
    BIND version 9.3.4
    Dovecot Version 1.0.7 (which is not running as of yet)
    Sendmail version 8.13.8
    OpenSSH_4.3
    Webmin 1.43

    Thanks!

    -Michael

  2. #2
    Join Date
    Jan 2006
    Location
    Athens, Greece
    Posts
    1,481
    Even if you don't share your server, you have virtual hosts who "share" the machine. One site hacked, gets all sites hacked.
    If you are using a custom setup with no control panel, install PHP and run it
    with FastCGI. With this setup the scripts will execute as their owner. That's my recommendation.

  3. #3
    Quote Originally Posted by Steve_Arm View Post
    Even if you don't share your server, you have virtual hosts who "share" the machine. One site hacked, gets all sites hacked.
    So, you are suggesting that I run each vhost as it's own user?

    When I was initially setting it up, I ran into a problem that requires me to run these commands every time I set up a new vhost (more info here):

    chown apacheuser:apachegroup /home/*
    chcon -R -t httpd_user_content_t /home/*

    If I go to individual users, I would use those users/groups in the first line? Or is that irrelevant?


    Quote Originally Posted by Steve_Arm View Post
    If you are using a custom setup with no control panel,
    I am using webmin, not sure that it matters though.

    Quote Originally Posted by Steve_Arm View Post
    install PHP and run it
    with FastCGI. With this setup the scripts will execute as their owner. That's my recommendation.
    PHP is installed already. Do you mean reinstall it, or reconfigure the existing install? Also, would this be in lieu of PHPsuexec?

    Thanks.

    -Michael

  4. #4
    Join Date
    Jan 2006
    Location
    Athens, Greece
    Posts
    1,481
    To wrap all your questions in one answer:
    Basically, each virtual domain is represented by an OS user.
    You will have to enable mod_suexec in Apache. It deals with permissions on the cgi scripts, then add mod_fastcgi.
    In Apache's vhosts conf file you tell Apache which is the user that the script should execute as. It's a pretty advance setup to set it like this, but worth the trouble. You have to disable the mod_php and install the cgi binary of it, probably it is already compiled on your machine.

  5. #5
    Ok, I installed FastCGI on my box using the following:

    Code:
    wget http://www.fastcgi.com/dist/fcgi-2.4.0.tar.gz
    tar -xzf fcgi-2.4.0.tar.gz
    cd fcgi-2.4.0
    ./configure
    make
    make install
    cd ../
    Thing is, I am pretty sure I did a yum install of PHP. The FastCGI instructions aren't that detailed. Here is what they say:

    First of all, build PHP. All of versions 4 and versions 5 supports the FastCGI flag. Simply specify where to get the FastCGI libraries from (download and install them from the http://www.fastcgi.com website), and do the normal build with whatever other options you require:

    ./configure [ your options ] --with-fastcgi=/usr/local

    This creates a version of PHP which speaks the FastCGI protocol.
    1) Since I didn't build PHP on the machine on the first place, do I need to do a from-scratch manual install?

    2) If so, do I need to remove the current installation first, and if so to that as well, how? I simply "yum remove php", right?

    Thanks.

    -Michael

  6. #6
    Join Date
    Jan 2006
    Location
    Athens, Greece
    Posts
    1,481

  7. #7
    Quote Originally Posted by Steve_Arm View Post
    Thanks, but that still doesn't answer my questions, since it assumes a clean box. It's an existing LAMP server, with Apache, MySQL, and PHP all installed using yum. Apache already has mod_suexec installed and running, and I installed fastcgi yesterday... what I need to know is:

    1) Since I didn't build PHP on the machine on the first place, do I need to do a from-scratch manual install? (my assumption is yes, but since I have never done this before I wanted to confirm)

    and

    2) If so, do I need to remove the current installation first, and if so to that as well, how? I simply "yum remove php", right? (again, I am assuming yes, especially since I plan to simply install the same version that is installed now, 5.1.6, and just copy over the existing ./config command and append "--with-fastcgi=/usr/local" at the end of it)

    If, however, there is a way to modify the current build off of the yum install, would that be better?

    Thanks again.

    -Michael

  8. #8
    Join Date
    Feb 2002
    Location
    Vestal, NY
    Posts
    1,381
    One thing to note is that under a non-suexec PHP setup, a hacked PHP script will give the user access as the OS user the webserver is running under. In some situations, this is good. If you have only one site, the user "apache" or "nobody" will not own most of the files and has no real privledges.

    Under suPHP, the hacked PHP script, depending on your configuration, will be running as the same user that owns the rest of the files on that virtual host. Therefore, the hacker now has access to delete/modify everything under that domain. Sometimes, this includes access to mail files, logs files, and much more.

    We tend to go non-suexec with CGI and PHP in cases where there is only one website or domain on a server. It can limit damage significantly, especially if there are no important files that are created by PHP or CGI scripts with ownership by the web server user.
    H4Y Technologies LLC .. Since 2001!!
    "Smarter, Cheaper, Faster" - SMB, Reseller, VPS, Dedicated, Colo hosting done right.

    ZERO PACKETLOSS, ZERO DOWNTIME Dedicated and Colo - USA: IA, CA, NC, OR, NV
    **http://h4y.us** **http://iwfhosting.net**
    Voice: (866)435-5642. *** askus at host4yourself d0t com

  9. #9
    Quote Originally Posted by John[H4Y] View Post
    ... in cases where there is only one website or domain on a server.
    As stated in the beginning, that is not the case here.

    -Michael

  10. #10
    Ok, here's where I am at, could really use some help if anyone can, thanks.

    Code:
    yum remove php
    wget http://www.php.net/get/php-5.2.6.tar.bz2/from/ar2.php.net/mirror
    tar -xjf php-5.2.6.tar.bz2
    cd php-5.2.6
    ./configure --build=i686-redhat-linux-gnu --host=i686-redhat-linux-gnu --target=i386-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --cache-file=../config.cache --with-libdir=lib --with-config-file-path=/etc --with-config-file-scan-dir=/etc/php.d --disable-debug --with-pic --disable-rpath --without-pear --with-bz2 --with-curl --with-exec-dir=/usr/bin --with-freetype-dir=/usr --with-png-dir=/usr --enable-gd-native-ttf --without-gdbm --with-gettext --with-gmp --with-iconv --with-jpeg-dir=/usr --with-openssl --with-png --with-pspell --with-expat-dir=/usr --with-pcre-regex=/usr --with-zlib --with-layout=GNU --enable-exif --enable-ftp --enable-magic-quotes --enable-sockets --enable-sysvsem --enable-sysvshm --enable-sysvmsg --enable-track-vars --enable-trans-sid --enable-yp --enable-wddx --with-kerberos --enable-ucd-snmp-hack --with-unixODBC=shared,/usr --enable-memory-limit --enable-shmop --enable-calendar --enable-dbx --enable-dio --with-mime-magic=/usr/share/file/magic.mime --without-sqlite --with-libxml-dir=/usr --with-xml --with-system-tzdata --with-apxs2=/usr/sbin/apxs --without-mysql --without-gd --without-odbc --disable-dom --disable-dba --without-unixODBC --disable-pdo --disable-xmlreader --disable-xmlwriter --with-fastcgi=/usr/local
    loading cache ../config.cache
    checking for Cygwin environment... no
    checking for mingw32 environment... no
    checking for egrep... grep -E
    checking for a sed that does not truncate output... /bin/sed
    checking host system type... i686-redhat-linux-gnu
    checking target system type... i386-redhat-linux-gnu
    checking for gcc... gcc
    checking whether the C compiler (gcc  ) works... yes
    checking whether the C compiler (gcc  ) is a cross-compiler... no
    checking whether we are using GNU C... yes
    checking whether gcc accepts -g... yes
    checking how to run the C preprocessor... gcc -E
    checking for icc... no
    checking whether gcc and cc understand -c and -o together... yes
    checking how to run the C preprocessor... gcc -E
    checking for AIX... no
    checking whether ln -s works... yes
    checking for system library directory... lib
    checking whether to enable runpaths... no
    checking if compiler supports -R... no
    checking if compiler supports -Wl,-rpath,... yes
    checking for re2c... no
    configure: warning: You will need re2c 0.12.0 or later if you want to regenerate PHP parsers.
    checking for gawk... gawk
    checking for bison... bison -y
    checking for bison version... 2.3 (ok)
    checking for flex... flex
    checking for yywrap in -lfl... yes
    checking lex output file root... lex.yy
    checking whether yytext is a pointer... yes
    checking for working const... yes
    checking for flex version... 2.5.4 (ok)
    checking whether to force non-PIC code in shared modules... no
    checking whether /dev/urandom exists... yes
    checking for pthreads_cflags... -pthread
    checking for pthreads_lib...
     
    Configuring SAPI modules
    checking for AOLserver support... no
    checking for Apache 1.x module support via DSO through APXS... no
    checking for Apache 1.x module support... no
    checking whether to enable Apache charset compatibility option... no
    checking for Apache 2.0 filter-module support via DSO through APXS... no
    checking for Apache 2.0 handler-module support via DSO through APXS...
     
    Sorry, I cannot run apxs.  Possible reasons follow:
     
    1. Perl is not installed
    2. apxs was not found. Try to pass the path using --with-apxs2=/path/to/apxs
    3. Apache was not built using --enable-so (the apxs usage page is displayed)
     
    The output of /usr/sbin/apxs follows:
    ./configure: line 6669: /usr/sbin/apxs: No such file or directory
    configure: error: Aborting
    The ./configure options, aside from the last one, were all copied directly from the phpinfo() output from the yum install, with the single quotes all removed. No clue why it is erroring out.

    Suggestions?

    Thanks.

    -Michael

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •