You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Marc Slemko <ma...@znep.com> on 1997/07/27 07:55:03 UTC

Re: mod_cgi/918: if not using suexec, apache forces user to use server gid/uid settings

[talking about the 

    if (!suexec_enabled) {
        if (!can_exec(&r->finfo))
            return log_scripterror(r, conf, FORBIDDEN,
                                   "file permissions deny server execution");
    }

code.  The PR submitter hacks in their own CGI wrapper somewhere, 
but Apache is refusing to execute scripts not world executable]

I think the current message is useful.  The one you get without it
isn't as nice.  I am all for making it easy for people to do their
own thing with Apache, but it seems to me they have to hack the
source anyway to do what they want, so it doesn't really make much
difference.


On Sat, 26 Jul 1997, Dean Gaudet wrote:

> The following reply was made to PR mod_cgi/918; it has been noted by GNATS.
> 
> From: Dean Gaudet <dg...@arctic.org>
> To: "Tyler J. Allison" <al...@nas.nasa.gov>
> Subject: Re: mod_cgi/918: if not using suexec, apache forces user to use  server gid/uid settings
> Date: Sat, 26 Jul 1997 22:06:09 -0700 (PDT)
> 
>  
>  I think I mentioned in my previous response that I have no idea why that
>  check is there to begin with.  It's probably just there to make the logged
>  errors "prettier".  I just wanted to check that in fact you did not have
>  o+x set.  I'll see about removing it.
>  
>  Thanks
>  Dean
>  
> 


Re: mod_cgi/918: if not using suexec, apache forces user to use server gid/uid settings

Posted by Dean Gaudet <dg...@arctic.org>.
On Sat, 26 Jul 1997, Dean Gaudet wrote:

> For suexec that's true.  But it does not seem to be true otherwise.

i.e. (my fingers are tired too) I do not see how this applies to PR#918. 
Apache has no intimate knowledge of the wrapper, and hence is testing if
it can_exec the wrapper itself rather than the ultimate cgi. 

Dean


Re: mod_cgi/918: if not using suexec, apache forces user to use server gid/uid settings

Posted by Dean Gaudet <dg...@arctic.org>.
For suexec that's true.  But it does not seem to be true otherwise.

Dean

On Sun, 27 Jul 1997, Marc Slemko wrote:

> On Sat, 26 Jul 1997, Dean Gaudet wrote:
> 
> > No no, I'm talking pure unix exec here.  If I'm uid N, gid M, then either
> > o+x has to be set on the executable, or the exe's uid has to be N and u+x
> > set, or it's gid has to be M and g+x set.
> > 
> > That is exactly what can_exec checks. 
> > 
> > What is wrong?
> > 
> > Or is it checking the permissions on the ultimate cgi that's going to be
> > executed rather than checking permissions on the wrapper?? 
> 
> To save my tired fingers:
> 
> > The server looks at the permissions on the script that suexec will
> > execute, not the permissions on suexec.  Since when suexec eventually gets
> 
> (that's a yes to your question.  <g>)
> 
> > 
> > Dean
> > 
> > On Sun, 27 Jul 1997, Marc Slemko wrote:
> > 
> > > No.  The server looks at the permissions on the script that suexec will
> > > execute, not the permissions on suexec.  Since when suexec eventually gets
> > > around to running the script, it will probably be as a different UID,
> > > checking based on the view of the user who runs suexec doesn't make sense.
> > > 
> > > The code could be expanded to know what user will be passed to suexec, but
> > > it hasn't been.
> > > 
> > > On Sat, 26 Jul 1997, Dean Gaudet wrote:
> > > 
> > > > On Sat, 26 Jul 1997, Marc Slemko wrote:
> > > > > No.  can_exec just doesn't know about magic user ID changes like those
> > > > > that happen using suexec or some other wrapper.  It checks to see if it
> > > > > can be execed given the user ID the server is running as now.  
> > > > 
> > > > Um yes, well, what other uid is the server going to attempt to execute it
> > > > as? 
> > > > 
> > > > Am I totally confused?  I thought these things were setuid root (in the
> > > > case of suexec), or setuid user (in the case of cgiwrap).  In either case
> > > > the webserver needs permission to execute the file.  That's either group
> > > > or other x that needs to be set.
> > > > 
> > > > Dean
> > > > 
> > > > 
> > > 
> > > 
> > 
> 
> 


Re: mod_cgi/918: if not using suexec, apache forces user to use server gid/uid settings

Posted by Marc Slemko <ma...@worldgate.com>.
On Sat, 26 Jul 1997, Dean Gaudet wrote:

> No no, I'm talking pure unix exec here.  If I'm uid N, gid M, then either
> o+x has to be set on the executable, or the exe's uid has to be N and u+x
> set, or it's gid has to be M and g+x set.
> 
> That is exactly what can_exec checks. 
> 
> What is wrong?
> 
> Or is it checking the permissions on the ultimate cgi that's going to be
> executed rather than checking permissions on the wrapper?? 

To save my tired fingers:

> The server looks at the permissions on the script that suexec will
> execute, not the permissions on suexec.  Since when suexec eventually gets

(that's a yes to your question.  <g>)

> 
> Dean
> 
> On Sun, 27 Jul 1997, Marc Slemko wrote:
> 
> > No.  The server looks at the permissions on the script that suexec will
> > execute, not the permissions on suexec.  Since when suexec eventually gets
> > around to running the script, it will probably be as a different UID,
> > checking based on the view of the user who runs suexec doesn't make sense.
> > 
> > The code could be expanded to know what user will be passed to suexec, but
> > it hasn't been.
> > 
> > On Sat, 26 Jul 1997, Dean Gaudet wrote:
> > 
> > > On Sat, 26 Jul 1997, Marc Slemko wrote:
> > > > No.  can_exec just doesn't know about magic user ID changes like those
> > > > that happen using suexec or some other wrapper.  It checks to see if it
> > > > can be execed given the user ID the server is running as now.  
> > > 
> > > Um yes, well, what other uid is the server going to attempt to execute it
> > > as? 
> > > 
> > > Am I totally confused?  I thought these things were setuid root (in the
> > > case of suexec), or setuid user (in the case of cgiwrap).  In either case
> > > the webserver needs permission to execute the file.  That's either group
> > > or other x that needs to be set.
> > > 
> > > Dean
> > > 
> > > 
> > 
> > 
> 


Re: mod_cgi/918: if not using suexec, apache forces user to use server gid/uid settings

Posted by Dean Gaudet <dg...@arctic.org>.
No no, I'm talking pure unix exec here.  If I'm uid N, gid M, then either
o+x has to be set on the executable, or the exe's uid has to be N and u+x
set, or it's gid has to be M and g+x set.

That is exactly what can_exec checks. 

What is wrong?

Or is it checking the permissions on the ultimate cgi that's going to be
executed rather than checking permissions on the wrapper?? 

Dean

On Sun, 27 Jul 1997, Marc Slemko wrote:

> No.  The server looks at the permissions on the script that suexec will
> execute, not the permissions on suexec.  Since when suexec eventually gets
> around to running the script, it will probably be as a different UID,
> checking based on the view of the user who runs suexec doesn't make sense.
> 
> The code could be expanded to know what user will be passed to suexec, but
> it hasn't been.
> 
> On Sat, 26 Jul 1997, Dean Gaudet wrote:
> 
> > On Sat, 26 Jul 1997, Marc Slemko wrote:
> > > No.  can_exec just doesn't know about magic user ID changes like those
> > > that happen using suexec or some other wrapper.  It checks to see if it
> > > can be execed given the user ID the server is running as now.  
> > 
> > Um yes, well, what other uid is the server going to attempt to execute it
> > as? 
> > 
> > Am I totally confused?  I thought these things were setuid root (in the
> > case of suexec), or setuid user (in the case of cgiwrap).  In either case
> > the webserver needs permission to execute the file.  That's either group
> > or other x that needs to be set.
> > 
> > Dean
> > 
> > 
> 
> 


Re: mod_cgi/918: if not using suexec, apache forces user to use server gid/uid settings

Posted by Marc Slemko <ma...@worldgate.com>.
No.  The server looks at the permissions on the script that suexec will
execute, not the permissions on suexec.  Since when suexec eventually gets
around to running the script, it will probably be as a different UID,
checking based on the view of the user who runs suexec doesn't make sense.

The code could be expanded to know what user will be passed to suexec, but
it hasn't been.

On Sat, 26 Jul 1997, Dean Gaudet wrote:

> On Sat, 26 Jul 1997, Marc Slemko wrote:
> > No.  can_exec just doesn't know about magic user ID changes like those
> > that happen using suexec or some other wrapper.  It checks to see if it
> > can be execed given the user ID the server is running as now.  
> 
> Um yes, well, what other uid is the server going to attempt to execute it
> as? 
> 
> Am I totally confused?  I thought these things were setuid root (in the
> case of suexec), or setuid user (in the case of cgiwrap).  In either case
> the webserver needs permission to execute the file.  That's either group
> or other x that needs to be set.
> 
> Dean
> 
> 


Re: mod_cgi/918: if not using suexec, apache forces user to use server gid/uid settings

Posted by Dean Gaudet <dg...@arctic.org>.
On Sat, 26 Jul 1997, Marc Slemko wrote:
> No.  can_exec just doesn't know about magic user ID changes like those
> that happen using suexec or some other wrapper.  It checks to see if it
> can be execed given the user ID the server is running as now.  

Um yes, well, what other uid is the server going to attempt to execute it
as? 

Am I totally confused?  I thought these things were setuid root (in the
case of suexec), or setuid user (in the case of cgiwrap).  In either case
the webserver needs permission to execute the file.  That's either group
or other x that needs to be set.

Dean



Re: mod_cgi/918: if not using suexec, apache forces user to use server gid/uid settings

Posted by Marc Slemko <ma...@worldgate.com>.
On Sat, 26 Jul 1997, Dean Gaudet wrote:

> Yes well we could check can_exec after a script failure instead of before

Ick.

> ... but I still don't understand how the user's cgiwrap is being invoked
> if it doesn't pass can_exec.

They probably hacked it into util_script in a similar way to the way
suexec is done.  I can't see it being anything like cgiwrap where you use
PATH_INFO.

> 
> For that matter, why does suexec need can_exec disabled too?
> 
> One of the x bits has to be set.  Is can_exec broken?

No.  can_exec just doesn't know about magic user ID changes like those
that happen using suexec or some other wrapper.  It checks to see if it
can be execed given the user ID the server is running as now.  

API_EXPORT(int) can_exec(const struct stat *finfo) {
#ifdef MULTIPLE_GROUPS
  int cnt;
#endif
#if defined(__EMX__) || defined(WIN32)
    /* OS/2 dosen't have Users and Groups */
    return 1;
#else    
    if(user_id == finfo->st_uid)
        if(finfo->st_mode & S_IXUSR)
            return 1;
    if(group_id == finfo->st_gid)
        if(finfo->st_mode & S_IXGRP)
            return 1;
#ifdef MULTIPLE_GROUPS
    for(cnt=0; cnt < NGROUPS_MAX; cnt++) {
        if(group_id_list[cnt] == finfo->st_gid)
            if(finfo->st_mode & S_IXGRP)
                return 1;
    }
#endif
    return (finfo->st_mode & S_IXOTH);
#endif    
}


> 
> Dean
> 
> On Sat, 26 Jul 1997, Marc Slemko wrote:
> 
> > [talking about the 
> > 
> >     if (!suexec_enabled) {
> >         if (!can_exec(&r->finfo))
> >             return log_scripterror(r, conf, FORBIDDEN,
> >                                    "file permissions deny server execution");
> >     }
> > 
> > code.  The PR submitter hacks in their own CGI wrapper somewhere, 
> > but Apache is refusing to execute scripts not world executable]
> > 
> > I think the current message is useful.  The one you get without it
> > isn't as nice.  I am all for making it easy for people to do their
> > own thing with Apache, but it seems to me they have to hack the
> > source anyway to do what they want, so it doesn't really make much
> > difference.
> > 
> > 
> > On Sat, 26 Jul 1997, Dean Gaudet wrote:
> > 
> > > The following reply was made to PR mod_cgi/918; it has been noted by GNATS.
> > > 
> > > From: Dean Gaudet <dg...@arctic.org>
> > > To: "Tyler J. Allison" <al...@nas.nasa.gov>
> > > Subject: Re: mod_cgi/918: if not using suexec, apache forces user to use  server gid/uid settings
> > > Date: Sat, 26 Jul 1997 22:06:09 -0700 (PDT)
> > > 
> > >  
> > >  I think I mentioned in my previous response that I have no idea why that
> > >  check is there to begin with.  It's probably just there to make the logged
> > >  errors "prettier".  I just wanted to check that in fact you did not have
> > >  o+x set.  I'll see about removing it.
> > >  
> > >  Thanks
> > >  Dean
> > >  
> > > 
> > 
> > 
> 


Re: mod_cgi/918: if not using suexec, apache forces user to use server gid/uid settings

Posted by Dean Gaudet <dg...@arctic.org>.
Yes well we could check can_exec after a script failure instead of before
... but I still don't understand how the user's cgiwrap is being invoked
if it doesn't pass can_exec.

For that matter, why does suexec need can_exec disabled too?

One of the x bits has to be set.  Is can_exec broken?

Dean

On Sat, 26 Jul 1997, Marc Slemko wrote:

> [talking about the 
> 
>     if (!suexec_enabled) {
>         if (!can_exec(&r->finfo))
>             return log_scripterror(r, conf, FORBIDDEN,
>                                    "file permissions deny server execution");
>     }
> 
> code.  The PR submitter hacks in their own CGI wrapper somewhere, 
> but Apache is refusing to execute scripts not world executable]
> 
> I think the current message is useful.  The one you get without it
> isn't as nice.  I am all for making it easy for people to do their
> own thing with Apache, but it seems to me they have to hack the
> source anyway to do what they want, so it doesn't really make much
> difference.
> 
> 
> On Sat, 26 Jul 1997, Dean Gaudet wrote:
> 
> > The following reply was made to PR mod_cgi/918; it has been noted by GNATS.
> > 
> > From: Dean Gaudet <dg...@arctic.org>
> > To: "Tyler J. Allison" <al...@nas.nasa.gov>
> > Subject: Re: mod_cgi/918: if not using suexec, apache forces user to use  server gid/uid settings
> > Date: Sat, 26 Jul 1997 22:06:09 -0700 (PDT)
> > 
> >  
> >  I think I mentioned in my previous response that I have no idea why that
> >  check is there to begin with.  It's probably just there to make the logged
> >  errors "prettier".  I just wanted to check that in fact you did not have
> >  o+x set.  I'll see about removing it.
> >  
> >  Thanks
> >  Dean
> >  
> > 
> 
>