Here is a patch for better reference with comments:

--- ./modules/mappers/mod_userdir.c	2006-07-12 05:38:44.000000000 +0200
+++ ../mod_userdir.c	2009-05-10 17:38:36.048667150 +0200
@@ -186,9 +186,11 @@
     const userdir_config *s_cfg;
     char *name = r->uri;
     const char *userdirs;
+    request_rec *notes_req;
     const char *w, *dname;
     char *redirect;
     apr_finfo_t statbuf;
+    
 
     /*
      * If the URI doesn't match our basic pattern, we've nothing to do with
@@ -312,8 +314,17 @@
             if (*userdirs && dname[0] == 0)
                 r->finfo = statbuf;
 
+            /* We could be servicing a sub-request; make sure we put notes
+             * on the main request.
+             */
+            if (r->main) {
+                notes_req = r->main;
+            } else {
+                notes_req = r;
+            }
+
             /* For use in the get_suexec_identity phase */
-            apr_table_setn(r->notes, "mod_userdir_user", w);
+            apr_table_setn(notes_req->notes, "mod_userdir_user", w);
 
             return OK;
         }

Just tested that patch applies cleanly to 2.2.15.

Should I reassign it to mod_suexec possibly?

thanks for the patch. i installed it on centos v5.5, apache v2.2, php v5.2.13. after restarting apache i still get 500 error when using /~username and suexec enabled. i am running PHP as fcgi. however, running php as mod_php (DSO) or suPHP doesn't cause the 500 error.

thanks,
john

thanks for the patch. i installed it on centos v5.5, apache v2.2, and php v5.2.13. i restarted apache and still get 500 error. my PHP is using fast cgi.

(In reply to comment #5)
> thanks for the patch. i installed it on centos v5.5, apache v2.2, and php
> v5.2.13. i restarted apache and still get 500 error. my PHP is using fast cgi.

The configuration is quite complicated, this is how I make it working on my system:

I have apache2 configured with mod_userdir + mod_suexec + mod_fcgid (for
runing php5-cgi in my case).

On Debian I make:

server# apt-get install apache2 apache2-suexec libapache2-mod-fcgid php5-cgi
server# a2enmod actions suexec userdir fcgid

Be sure to disable mod_php or even uninstall it from system.
server# a2dismod php

Then I have edited  /etc/apache2/sites-available/default and ADDED this at the end:

	SuexecUserGroup www-data www-data
	<Directory /var/www>
		Action php-fcgi /fcgi-bin/php-fcgi-wrapper
	</Directory>
	<Directory /home/*/public_html/>
		AllowOverride FileInfo AuthConfig Limit
		Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
		Order allow,deny
		Allow from all
	</Directory>
	ScriptAliasMatch ^/~([^/]*)/fcgi-bin/(.*) /home/$1/public_html/fcgi-bin/$2
	<Directory /home/*/public_html/fcgi-bin>
		AllowOverride None
		Options ExecCGI -MultiViews +SymLinksIfOwnerMatch
		SetHandler fcgid-script
		Order allow,deny
		Allow from all
	</Directory>

server# cat /etc/apache2/conf.d/php-fcgid.conf
  <IfModule !mod_php4.c>
  <IfModule !mod_php4_filter.c>
  <IfModule !mod_php5.c>
  <IfModule !mod_php5_filter.c>
  <IfModule !mod_php5_hooks.c>
  <IfModule mod_actions.c>
  <IfModule mod_alias.c>
  <IfModule mod_mime.c>
  <IfModule mod_fcgid.c>
    # Path to php.ini – defaults to /etc/phpX/cgi
    DefaultInitEnv PHPRC=/etc/php5/cgi

    # Number of PHP childs that will be launched. Leave undefined to let PHP decide.
    #DefaultInitEnv PHP_FCGI_CHILDREN 3

    # Maximum requests before a process is stopped and a new one is launched
    #DefaultInitEnv PHP_FCGI_MAX_REQUESTS 5000

    # Define a new handler "php-fcgi" for ".php" files, plus the action that must follow
    AddHandler php-fcgi .php
    Action php-fcgi /fcgi-bin/php-fcgi-wrapper

    # Define the MIME-Type for ".php" files
    AddType application/x-httpd-php .php

    # Define alias "/fcgi-bin/". The action above is using this value, which means that
    # you could run another "php5-cgi" command by just changing this alias
    #Alias /fcgi-bin/ /var/www/fcgi-bin.d/php5-default/

    # Turn on the fcgid-script handler for all files within the alias "/fcgi-bin/"
    <Location /fcgi-bin/>
        SetHandler fcgid-script
        Options +ExecCGI
    </Location>
  </IfModule>
  </IfModule>
  </IfModule>
  </IfModule>
  </IfModule>
  </IfModule>
  </IfModule>
  </IfModule>
  </IfModule>

server# cat /home/baryluk/public_html/test.php
  <?php
  system("whoami");
  echo "<br/>";
  echo "<br/>";
  system("id");
  echo "<br/>";
  echo "<br/>";
  phpinfo();
  ?>
server# cat /home/baryluk/public_html/.htaccess
  Action php-fcgi /~baryluk/fcgi-bin/php-fcgi-wrapper
server# cat /home/baryluk/public_html/fcgi-bin/php-fcgi-wrapper
  #!/bin/sh
  exec /usr/bin/php5-cgi
server# chmod +x /home/baryluk/public_html/fcgi-bin/php-fcgi-wrapper
server# chown -R baryluk:users /home/baryluk/public_html
server# /etc/init.d/apache2 restart



In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528062#20 you can find attachmens which can simplify setup.


This setup on stock Apache server, when visiting http://localhost/~baryluk/test.php, works, but shows "www-data". After using patch, it shows baryluk, as expected.

I'm using apache2-mpm-worker 2.2.15-5 package and libapache2-mod-fcgid 1:2.3.5-2, php5-cgi 5.3.2-1.


Apache will run with one process at the "root" user, and few workers with "www-data". It will also spawn fcgi using suexec when accessing user fcgi scripts, including php in userdirs, if configured as above. Static files in userdir will still be served using "www-data" user, so be sure that public_html directory and its content is readable, also when php scripts will create some files, I have ACL for this:

server# getfacl home/baryluk
# file: home/baryluk
# owner: baryluk
# group: users
user::rwx
group::---
group:www-data:--x
mask::--x
other::---

server# getfacl home/baryluk/public_html
# file: home/baryluk/public_html
# owner: baryluk
# group: users
user::rwx
group::---
group:www-data:r-x
mask::rwx
other::---
default:user::rwx
default:group::---
default:group:www-data:r-x
default:mask::r-x
default:other::---

Can you give a repro case with the simplest possible configuration for this?

It's not obvious to me why unconditionally propagating the userdir identity from a subrequest to the main request (which may be of a URI outside userdir-enabled space) is a good idea.

(In reply to comment #7)
> Can you give a repro case with the simplest possible configuration for this?

I already given reproduction case. It is very simple case. I cannot minimize it in any way. It really is just few files to be put in clean installation (preferably Debian), with php5-cgi as example and eventually edit them to make username be proper. I can try using pure cgi without fcgi, and trying to run some simple bash cgi, without php if you wish.

> 
> It's not obvious to me why unconditionally propagating the userdir identity
> from a subrequest to the main request (which may be of a URI outside
> userdir-enabled space) is a good idea.

This is exactly a  comment I was waiting for! I was sure that there are some cases it is bad.

As I understand subrequest will be made on redirect/rewrite or server includes right?

Even then I do not think it is much unsafe, as when using suexec whole server is already running as root, or www-data, which have quite big permission to all files. So changing uid cannot make it worse, in my opinion. It will not give access to more that it already have. (Becuase most often www-data already have read permiossion to most user files). But of course if it would be possible to switch by one user to other's user UID then indeeded, things like deleting others file would be a problem. 

When this "switch" happens?
On server includes? (i do not exactly understand what is "subrequest" unfortunetly).
Can subrequests be done recursivly? (subrequest of subrequest?).

>    ScriptAliasMatch ^/~([^/]*)/fcgi-bin/(.*) /home/$1/public_html/fcgi-bin/$2
>    Action php-fcgi /fcgi-bin/php-fcgi-wrapper

This is causing an internal redirect, to hit the fcgi interpreter with an argument of your script, which is not tagged with the userdir identity.

Unclear whether this particular case should find a way to remember, and if that would live in the fastcgi module, userdir, or elsewhere, but I'm sure in general there are cases where the userdir identity should not tag along.

Sorry to all but,

I need help to get my server running with mod_userdir: so my question is how do I apply the patch for Apache 2 ???

Here is my post for this issue after overcoming all errors related with suexec and virtual hosts one per domain: http://www.howtoforge.com/forums/showthread.php?p=285160#post285160
Is it possible to adapt the solution with my proposal at the post of this forum?

I can see plus and minus symbols at the patch. What are they?
From my post you can see that I followed with success Falco's post (http://www.howtoforge.com/how-to-set-up-apache2-with-mod_fcgid-and-php5-on-ubuntu-11.10) which I think is much more elegant than "Witold Baryluk" approach.

Thank you for any help!

PS: there are other grey areas in Witold Baryluk's post like: 
".....also when php scripts will create some files, I have ACL for this:

server# getfacl home/baryluk
# file: home/baryluk
....."
ACL what???

(In reply to Witold Baryluk from comment #8)
> (In reply to comment #7)
> > Can you give a repro case with the simplest possible configuration for this?
> 
> I already given reproduction case. It is very simple case. I cannot minimize
> it in any way. It really is just few files to be put in clean installation
> (preferably Debian), with php5-cgi as example and eventually edit them to
> make username be proper. I can try using pure cgi without fcgi, and trying
> to run some simple bash cgi, without php if you wish.
> 
> > 
> > It's not obvious to me why unconditionally propagating the userdir identity
> > from a subrequest to the main request (which may be of a URI outside
> > userdir-enabled space) is a good idea.
> 
> This is exactly a  comment I was waiting for! I was sure that there are some
> cases it is bad.
> 
> As I understand subrequest will be made on redirect/rewrite or server
> includes right?
> 
> Even then I do not think it is much unsafe, as when using suexec whole
> server is already running as root, or www-data, which have quite big
> permission to all files. So changing uid cannot make it worse, in my
> opinion. It will not give access to more that it already have. (Becuase most
> often www-data already have read permiossion to most user files). But of
> course if it would be possible to switch by one user to other's user UID
> then indeeded, things like deleting others file would be a problem. 
> 
> When this "switch" happens?
> On server includes? (i do not exactly understand what is "subrequest"
> unfortunetly).
> Can subrequests be done recursivly? (subrequest of subrequest?).

Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.

The issue is still present in Apache 2.4.46.

Without the patch, I am getting 500 Internal server error, and in suexec.log this message:

[2020-12-05 10:12:27]: cannot run as forbidden uid (33/php-fcgi-wrapper)
[2020-12-05 10:23:09]: uid: (1000/user) gid: (1000/user) cmd: php-fcgi-wrapper

With the patch it just works.

Tested php8.0-cgi 8.0.0-1 from Debian sid.

The configuration is essentially the same as before (slightly adjusted because Debian packages Apache 2.4 is a bit different than Apache 2.2 in the past, i.e. it is split differently into different files now).

The patch is the same, just variable `w` is now `user`.