[users@httpd] Script behaving differently when run by Apache and when run from a shell by user www-data?

[EML]

The CGI Howto page contains some basic information on how Apache 
actually runs a program, but is there any more detailed information 
anywhere?


Specifically, I have a problem where a bash script runs as expected when 
run from an interactive shell by user www-data (this is Ubuntu). 
However, the script behaves differently when run via Apache from a web 
client. This is nothing to do with PATH or envvar differences: when run 
by Apache, an operation to unmount a disk appears to succeed, but 
actually doesn't unmount the disk. When run from the interactive shell, 
as the same user, the operation unmounts the disk.


This is a basic Apache install on Ubuntu 22.04 - no suexec, no chroot, 
plain CGI, etc. I've been running scripts via Apache this way for years, 
but this is the first script which attempts to carry out disk 
operations. All these scripts appear in the sudoers file to allow Apache 
to carry out specific privileged operations.


I asked this question  
today on StackExchange (https://unix.stackexchange.com/q/767587/212513, 
if the link is scrubbed), with much more detail, but I think that was 
probably the wrong place to ask.


 Thanks.

Fwd: [users@httpd] Script behaving differently when run by Apache and when run from a shell by user www-data?

[EML]

Let's take a step back - why are you unmounting from a cgi script?


It's a one-time setup when a user configures a new system. Most of these 
users aren't shell-literate, so they configure by ticking boxes on a web 
page. The system is a VPS, so is actually a VM, which I hope isn't relevant.


Anyway, when configuration completes, all the scripts are deleted and 
Apache runs 'normally'.

Re: [users@httpd] Script behaving differently when run by Apache and when run from a shell by user www-data?

[EML]

IMO suexec would be better suited to handle more sensitive operations 
such as unmounting.


CGI is not an interactive shell, as you discovered.

Calling a separate script with the suid bit might work too.


But I don't need an interactive shell: I need a way to run a script as 
user www-data, which is what CGI is for. I tested the script in an 
interactive shell because that's the easy way to run a script as user 
www-data.


What's interesting here is that CGI appears to be doing something more 
complex than simply forking a process. The script which is the problem 
has an EUID of 0, so why can't it unmount a filesystem? Have I just 
messed up (probably?) Or has Apache run me /without/ CAP_SYS_ADMIN? If 
so, how and why? Maybe this is unlikely, but if it happens, it should be 
documented. If this, or something similar, doesn't happen, then I know 
that the problem is my fault.

Re: [users@httpd] Script behaving differently when run by Apache and when run from a shell by user www-data?

[EML]

Hi Alan - spot on; thank you. To save having to learn about namespaces 
I've just started Apache without 'PrivateTmp' in the service file, and 
the script now works as expected (and 'lsns' no longer shows Apache as 
having its own mount namespace).


journalctl also now shows that systemd unmounts my device after the 
script issues the umount command, which it didn't before.


Disabling PrivateTmp isn't a great solution, but this is a one-off 
config, so I can restore it afterwards. If you want to answer the SO 
question I'll accept it.


On 24/01/2024 13:47, Curry, Alan wrote:

On 1/23/2024 3:58 PM, EML wrote:


What's interesting here is that CGI appears to be doing something more
complex than simply forking a process. The script which is the problem
has an EUID of 0, so why can't it unmount a filesystem? Have I just
messed up (probably?) Or has Apache run me /without/ CAP_SYS_ADMIN? If

Or is Apache in an isolated namespace, making its mount and unmount
operations invisible to most other processes?

You can investigate by comparing what /proc/$$/ns/mnt looks like inside
and outside the problematic script. If this is the case, you might need
to use nsenter(1) to access the namespace(s) in which you want your
unmount to take effect.

[users@httpd] Ubuntu 22.04/Apache 2.4.58 can enable cgid, but not cgi

[EML]

This combination (22.04.2/2.4.58) defaults to mpm_prefork. I have a 
previous (working) Apache config which uses mod_cgid, and which sets 
'CGIDScriptTimeout'. Since this is a non-threading prefork system, I've 
attempted to change 'CGIDScriptTimeout' to 'CGIScriptTimeout'. However, 
this doesn't work: 'apachectl -M' reports a syntax error at 
'CGIScriptTimeout', and Apache doesn't start.


In more detail, I've:

1. Commented out the 'CGIScriptTimeout' line
2. Run 'a2enmod cgi'
3. Run 'lsof /usr/lib/apache2/modules/mod_cgi.so'. This confirms that
   the mod_cgi file is used by 7 processes; each process has the PID of
   an Apache2 instance
4. Run 'lsof /usr/lib/apache2/modules/mod_cgid.so'. This confirms that
   mod_cgid is unused
5. Uncommented the CGIScriptTimeout line
6. Run 'apachectl -M'. This reports a syntax error  on the
   'CGIScriptTimeout' line

I've also done the reverse: enabled mod_cgid, and replaced the 
'CGIScriptTimeout' with 'CGIDScriptTimeout', and confirmed that Apache 
runs and no syntax errors are reported. In this state, 'lsof' also 
confirms that mod_cgid.so is being used.


Questions:

1. Does anyone know what's going on here? Can I use plain mod_cgi with
   Ubuntu 22.04.2 and 2.4.58?
2. Is there actually a problem with running mod_cgid with mpm_prefork?
   I suspect not, but I haven't tested it yet
3. I'm not entirely sure why this setup defaults to mpm_prefork. I'm
   running legacy C++ which requires plain CGI, and php, with mod_php
   (libphp8.3.so).  Does libphp actually use mod_cgi[d], or is it using
   its own comms mechanism? Should I actually care if php is
   thread-safe or not?

Thanks.

Re: [users@httpd] Ubuntu 22.04/Apache 2.4.58 can enable cgid, but not cgi

[EML]

On 18/05/2025 02:29, Frank Gingras wrote:



First, you are free to change the mpm to event by commenting out the 
LoadModule directive for prefork, and uncommenting the LoadModule 
directive for event.  You will want to stop using the mod_php DSO if 
you change to the event mpm, mind you.


As for your other questions, mod_cgi is to be used with prefork, and 
mod_cgid for worker/event.  They don't mix.



Thanks, makes sense. Do you have any idea why CGIScriptTimeout is 
flagged as a syntax error for mod_cgi? All I did was change the existing 
'CGIDScriptTimeout 240' by removing the 'D', and Apache won't start, 
despite lsof showing that mod_cgi.so is loaded.

Re: [users@httpd] Ubuntu 22.04/Apache 2.4.58 can enable cgid, but not cgi

[EML]

On 18/05/2025 10:43, EML wrote:



On 18/05/2025 02:29, Frank Gingras wrote:



First, you are free to change the mpm to event by commenting out the 
LoadModule directive for prefork, and uncommenting the LoadModule 
directive for event.  You will want to stop using the mod_php DSO if 
you change to the event mpm, mind you.


As for your other questions, mod_cgi is to be used with prefork, and 
mod_cgid for worker/event.  They don't mix.



Thanks, makes sense. Do you have any idea why CGIScriptTimeout is 
flagged as a syntax error for mod_cgi? All I did was change the 
existing 'CGIDScriptTimeout 240' by removing the 'D', and Apache won't 
start, despite lsof showing that mod_cgi.so is loaded.



Ok... so the docs actually say that CGIDScriptTimeout was introduced in 
2.4.10, and CGIScriptTimeout in 2.4.59. Ubuntu 24.04.2 is on 2.4.58. My bad.

[users@httpd] Auth failure when a rewrite rule is moved out to an htaccess file

[EML]

I have a problem where authorisation behaves differently when a rewrite 
rule is moved from the main configuration to an .htaccess file. Any 
advice appreciated.


The site looks like this:

$ tree /var/www5
/var/www5
|-- dir1
    |-- test1.html
|-- dir2
|   |-- test2.html
|-- index.html
|-- passwords

I want the site to default to requiring a login, except that 
dir1/test1.html should be readable by anybody. There's a complication, 
which is that a rewrite rule sets the home page to dir1/test1.html, 
rather than index.html. So the expected HTTP status codes are:


http://localhost/                 200 (because of the rewrite)
http://localhost/index.html       401
http://localhost/dir1/test1.html  200
http://localhost/dir2/test2.html  401

This configuration works exactly as expected:


  DocumentRoot /var/www5

  
    AuthType Basic
    AuthName Test
    AuthBasicProvider file
    AuthUserFile "/var/www5/passwords"
    Require  valid-user
  

  
    
      Require all granted
    
  

  RewriteEngine On
  RewriteRule ^(/)?$ /dir1/test1.html [L]


Ok, here's the problem: I actually need to move the rewrite out to an 
.htaccess file, so I've moved the RewriteEngine and RewriteRule lines 
out to /var/www5/.htaccess. The new configuration file looks like:



  DocumentRoot /var/www5

  
    AuthType Basic
    AuthName Test
    AuthBasicProvider file
    AuthUserFile "/var/www5/passwords"
    Require  valid-user
  

  
    AllowOverride All
  

  
    
      Require all granted
    
  


This *doesn't* work. What I get now is:

http://localhost/                 401
http://localhost/index.html       401
http://localhost/dir1/test1.html  200
http://localhost/dir2/test2.html  401

I now have to log in to visit http://localhost/. The rewrite does work; 
if I log in, I get the dir1/test1.html page.


Thanks.