You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Rocke Robertson <ro...@tiger.pwgsc.gc.ca> on 2003/05/12 16:05:24 UTC

[PATCH 1.3] Add Solaris 9 Resource management features in suexec.c

> Here is my unified diff as requested by Justin E. It is worth emphasizing again that this
> code is only valid for Solaris 9 and will work on the newer Solaris releases as well,
> according to our local Sun SE.  The code in suexec.c is heavy in logging. Obviously this
> should be removed. To make it work, I changed the log entry in http_main.c, the makefile in
> src/support and suexec.c.

> Below is my patch created from a Solaris 9 system, using a unified diff.

> Cheers

> --- http_main.c.orig    Thu Feb 20 16:08:51 2003
> +++ http_main.c Fri May  9 09:12:20 2003
> @@ -3427,19 +3427,21 @@
>  #endif
>
>      /* close out the standard file descriptors */
> +
>      if (freopen("/dev/null", "r", stdin) == NULL) {
> -       fprintf(stderr, "%s: unable to replace stdin with /dev/null: %s\n",
> -               ap_server_argv0, strerror(errno));
> -       /* continue anyhow -- note we can't close out descriptor 0 because we
> -        * have nothing to replace it with, and if we didn't have a descriptor
> -        * 0 the next file would be created with that value ... leading to
> -        * havoc.
> -        */
> +        fprintf(stderr, "%s: unable to replace stdin with /dev/null: %s\n",
> +                ap_server_argv0, strerror(errno));
> +        /* continue anyhow -- note we can't close out descriptor 0 because we
> +         * have nothing to replace it with, and if we didn't have a descriptor
> +         * 0 the next file would be created with that value ... leading to
> +         * havoc.
> +         */
>      }
>      if (freopen("/dev/null", "w", stdout) == NULL) {
> -       fprintf(stderr, "%s: unable to replace stdout with /dev/null: %s\n",
> -               ap_server_argv0, strerror(errno));
> +        fprintf(stderr, "%s: unable to replace stdout with /dev/null: %s\n",
> +                ap_server_argv0, strerror(errno));
>      }
> +
>      /* stderr is a tricky one, we really want it to be the error_log,
>       * but we haven't opened that yet.  So leave it alone for now and it'll
>       * be reopened moments later.
> @@ -5107,8 +5109,13 @@
>         }
>
>         ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_NOTICE, server_conf,
> +                   "%s starting with SRM functionality",
> +                   ap_get_server_version());
> +
> +       ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_NOTICE, server_conf,
>                     "%s configured -- resuming normal operations",
>                     ap_get_server_version());
> +
>         if (ap_suexec_enabled) {
>             ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_NOTICE, server_conf,
>                          "suEXEC mechanism enabled (wrapper: %s)", SUEXEC_BIN);
> --- Makefile.configure  Fri Feb 28 08:23:33 2003
> +++ Makefile    Fri May  9 09:48:01 2003
> @@ -59,6 +59,7 @@
>  LIBS=-lm -lap -los $(EXTRA_LIBS) $(LIBS1)
>  INCLUDES=$(INCLUDES1) $(INCLUDES0) $(EXTRA_INCLUDES)
>  LDFLAGS=$(LDFLAGS1) $(EXTRA_LDFLAGS) -L$(OSDIR) -L$(SRCDIR)/ap
> +LDFLAGS_SUEXEC=$(LDFLAGS1) $(EXTRA_LDFLAGS) -L$(OSDIR) -L$(SRCDIR)/ap -lproject
>
>  TARGETS=htpasswd htdigest rotatelogs logresolve ab apxs checkgid
>
> @@ -98,7 +99,7 @@
>             -e 's%@LIBS_SHLIB@%$(LIBS_SHLIB)%g' && chmod a+x apxs
>
>  suexec: suexec.o
> -       $(CC) $(CFLAGS) -o suexec $(LDFLAGS) suexec.o $(LIBS)
> +       $(CC) $(CFLAGS) -o suexec $(LDFLAGS_SUEXEC) suexec.o $(LIBS)
>
>  clean:
>         rm -f $(TARGETS) *.o
> 92a93,95
> > #include <stdlib.h>
> > #include <project.h>
> >
> 280a284
> >
> 494c498
> <     if (userdir) {
> ---
> >  if (userdir) {
> 561a566
> >
> 563,571c568,576
> <       (gid != dir_info.st_gid) ||
> <       (uid != prg_info.st_uid) ||
> <       (gid != prg_info.st_gid)) {
> <       log_err("error: target uid/gid (%ld/%ld) mismatch "
> <               "with directory (%ld/%ld) or program (%ld/%ld)\n",
> <               uid, gid,
> <               dir_info.st_uid, dir_info.st_gid,
> <               prg_info.st_uid, prg_info.st_gid);
> <       exit(120);
> ---
> >         (gid != dir_info.st_gid) ||
> >         (uid != prg_info.st_uid) ||
> >         (gid != prg_info.st_gid)) {
> >         log_err("error: target uid/gid (%ld/%ld) mismatch "
> >                 "with directory (%ld/%ld) or program (%ld/%ld)\n",
> >                 uid, gid,
> >                 dir_info.st_uid, dir_info.st_gid,
> >                 prg_info.st_uid, prg_info.st_gid);
> >         exit(120);
> 620c625,679
> <     execv(cmd, &argv[3]);
> ---
> >
> >
> >  struct project pj_ptr;
> >  char buf[500];
> >  char projbuf[PROJNAME_MAX];                   /* see project.h */
> >  char cgi[256];
> >
> >  /* use target_uname to setup the project */
> >
> >  sprintf(projbuf,"user.%s",target_uname);
> >
> >  /* Since there is no . in the path, for the cgi/ssi execution
> >   * with a ./cgi . . Now, is this safe...? Check out later on.
> >   */
> >
> >  /* log_err("notice: project %s cwd %s\n",projbuf,cwd); */
> >  /* sprintf(cgi,"./%s",cmd); */
> >  snprintf(cgi,sizeof(cmd),"./%s",cmd);
> >
> >  /* Have to make SURE the project exists. If user.username doesn't exist
> >   * then set the project to the default project name. If that doesn't exist
> >   * either, then execute the SSI or CGI with no SRM functionality and log it.
> >   */
> >
> >  if (getprojbyname(projbuf,&pj_ptr,buf,sizeof(buf)) == NULL ) {
> >
> >     log_err("emerg: project (%s) doesn't exist. Correct httpd.conf entry!\n",projbuf);
> >     sprintf(projbuf,"default");
> >
> >     if (getprojbyname(projbuf,&pj_ptr,buf,sizeof(buf)) == NULL ) {
> >
> >         log_err("emerg: default project missing, executing without SRM functionality\n");
> >         if (execl(cgi,cgi,(char *) 0) < 0)
> >            log_err("crit: execl failed\n");
> >
> >     }
> >     else {            /* If default project exists, log it and run cgi */
> >
> >        log_err("emerg: using default project\n");
> >        log_err("notice: execing (%s) uid %d project %s\n",cgi,uid,projbuf);
> >        execl("/bin/newtask","newtask","-l","-p",projbuf,cgi,(char *) 0);
> >     }
> >
> >  }
> >  else {
> >
> >       /* user.default project exists, execute it! */
> >
> >    log_err("notice: execing (%s) uid %d project %s\n",cgi,uid,projbuf);
> >    if (execl("/bin/newtask","newtask","-l","-p",projbuf,cgi,(char *) 0) < 0)
> >       log_err("crit: execl failed\n");
> >  }
> >
> >  /* execv(buf, &argv[3]);*/
> >

--
Rocke Robertson
NCS/GTIS/PWGSC
700 Montreal Rd.
Rocker@tiger.pwgsc.gc.ca
(613) 748-4604



Re: [PATCH 1.3] Add Solaris 9 Resource management features in suexec.c

Posted by Rocke Robertson <ro...@tiger.pwgsc.gc.ca>.

Glenn wrote:

> [patch deleted; implemented Solaris 9 resource management with /bin/newtask]
>
> Why exec an additional program (/bin/newtask) when setproject() could be
> used instead?  The only difference of setproject() from the patch posted
> to this list is that /bin/newtask with -l creates the login environment,
> which is probably not desired.
>
> Cheers,
> Glenn

In order for a project to take effect when exec'ing something, the user has to
login. The way I did it was to use newtask -l -p etc..... But the setproject()
may work too. I would have to try it. Good point. I dont know why I didn't
originaly try it that way.

Will tinker around.

--
Rocke Robertson
NCS/GTIS/PWGSC
700 Montreal Rd.
Rocker@tiger.pwgsc.gc.ca
(613) 748-4604



Re: [PATCH 1.3] Add Solaris 9 Resource management features in suexec.c

Posted by Glenn <gs...@gluelogic.com>.
[patch deleted; implemented Solaris 9 resource management with /bin/newtask]

Why exec an additional program (/bin/newtask) when setproject() could be
used instead?  The only difference of setproject() from the patch posted
to this list is that /bin/newtask with -l creates the login environment,
which is probably not desired.

newtask(1)
  http://docs.sun.com/db/doc/816-0210/6m6nb7mfg?a=view

setproject(3PROJECT)
  http://docs.sun.com/db/doc/816-0217/6m6nhtaq8?a=view


FYI, for FreeBSD there is a patch to suexec to use login classes that is
languishing from Oct 2000 (http://bugs.apache.org/index.cgi/full/6673),
and adding PAM (pam_limits.so) support to suexec would be straightforward,
too.

Cheers,
Glenn