Loading ...
Sorry, an error occurred while loading the content.

Re: [mp2] running make test as unpriveleged user

Expand Messages
  • Stas Bekman
    ... certainly, but does it break anything? [...] ... This is not a portable change. If you have a particular problem with regards to temp dir it needs to be
    Message 1 of 6 , Oct 1, 2003
    • 0 Attachment
      Haroon Rafique wrote:
      > Hi,
      >
      > Find attached (and inline) a patch for smoother running of "make test"
      > when running as a non-privileged user. This issue came to light while
      > running Gentoo Linux. The Gentoo package system "portage" has the ability
      > to run as a non-root user while building packages. Some file locations
      > were not accessible to that non-root user while running make test. E.g.,
      > on Gentoo, mod_cgid defaults to using /var/run/cgisock for its sockets,
      > however, the permissions for /var/run/cgisock on Gentoo are:
      >
      > srwx------ 1 apache root 0 Oct 1 13:14 /var/run/cgisock
      >
      > I used the ScriptSock directive to tell mod_cgid to make the socket file
      > within the self-contained directory tree.
      >
      > Along the same lines, CGI.pm likes to create new temp files in /tmp. I
      > used the SetEnv directive to set TMPDIR environemnt variable to force it
      > to create the temp files in a self-contained directory tree.
      >
      > Comments are welcome. And we really should have a newline at the end of
      > ModPerl-Registry/t/conf/extra.conf.in

      certainly, but does it break anything?

      [...]

      > +SetEnv TMPDIR /tmp

      This is not a portable change. If you have a particular problem with regards
      to temp dir it needs to be solved where it arises (e.g. using File::Temp), but
      you don't tell what the problem is, so I can't give you a solution.

      > +ScriptSock logs/cgisock

      We don't use mod_cgi in the mod_perl test suite. It's just a left-over from
      testing. Does this patch fix things for you?

      Index: t/conf/extra.conf.in
      ===================================================================
      RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/t/conf/extra.conf.in,v
      retrieving revision 1.10
      diff -u -r1.10 extra.conf.in
      --- t/conf/extra.conf.in 5 Aug 2003 18:51:10 -0000 1.10
      +++ t/conf/extra.conf.in 1 Oct 2003 21:39:21 -0000
      @@ -35,8 +35,6 @@
      Alias /registry_oo_conf/ @ServerRoot@/cgi-bin/
      Alias /perlrun/ @ServerRoot@/cgi-bin/

      -ScriptAlias /cgi-bin/ @ServerRoot@/cgi-bin/
      -
      PerlModule ModPerl::RegistryBB
      <Location /registry_bb>
      PerlOptions +GlobalRequest


      __________________________________________________________________
      Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
      http://stason.org/ mod_perl Guide ---> http://perl.apache.org
      mailto:stas@... http://use.perl.org http://apacheweek.com
      http://modperlbook.org http://apache.org http://ticketmaster.com
    • Haroon Rafique
      On Today at 2:42pm, SB= Stas Bekman wrote: SB Comments are welcome. And we really should have a newline at the end of SB
      Message 2 of 6 , Oct 1, 2003
      • 0 Attachment
        On Today at 2:42pm, SB=>Stas Bekman <stas@...> wrote:

        SB> > Comments are welcome. And we really should have a newline at the end of
        SB> > ModPerl-Registry/t/conf/extra.conf.in
        SB>
        SB> certainly, but does it break anything?
        SB>

        Hi Stas,

        Doesn't break anything really, but when I was using the >> operator to
        tack on some directives at the end of this file not having the newline
        caused me some grief as the last line and my added line got stuck on the
        same line (oops that makes it a misspelled directive - sheepish grin :-))

        SB> [...]
        SB>
        SB> > +SetEnv TMPDIR /tmp
        SB>
        SB> This is not a portable change. If you have a particular problem with
        SB> regards to temp dir it needs to be solved where it arises (e.g. using
        SB> File::Temp), but you don't tell what the problem is, so I can't give
        SB> you a solution.

        I really should spend more time explaining the issue rather than jumping
        to the solution. Thanks for listening. Here's the issue. As I mentioned
        Gentoo's pacakge mgmt. system has the capability to build/install as a
        non-root user. Somewhere down line during the tests, the following tests
        are failing when run under the non-root user.

        modules/cgi....................NOK 3# Failed test 3 in modules/cgi.t at
        line 41
        modules/cgi....................FAILED test 3
        Failed 1/5 tests, 80.00% okay
        modules/cgiupload..............NOK 1# Failed test 1 in modules/cgiupload.t
        at line 32
        modules/cgiupload..............NOK 2# Failed test 2 in modules/cgiupload.t
        at line 32 fail #2
        modules/cgiupload..............FAILED tests 1-2
        Failed 2/2 tests, 0.00% okay

        Looing at t/logs/error_log, we find:

        [Wed Oct 01 18:15:18 2003] [error] (13)Permission denied: Couldn't unlink
        unix domain socket /var/run/cgisock
        [Wed Oct 01 18:15:18 2003] [error] (98)Address already in use: Couldn't
        bind unix domain socket /var/run/cgisock
        ACCESS DENIED unlink: /var/run/cgisock

        As I mentioned earlier, the permissions for /var/run/cgisock are not
        accissible by the non-root user. In addition, it is a violation of the
        sandbox principle. My fix for ScriptSock was meant to appease mod_cgid
        into creating the cgisock in the logs directory instead which will make it
        self-contained and won't violate the sandbox.

        In the case of SetEnv TMPDIR /tmp, CGI.pm uses /tmp as its temporary
        repository. Access to /tmp is again a violation of the sandbox. I agree
        that /tmp is not a portable solution but setting TMPDIR is the only way
        that I can think of to vary CGI.pm's behavior thru the httpd conf file.
        Perhaps, a kludge like:
        SetEnv TMPDIR logs
        would suffice. I believe CGI.pm cleans up after itself anyway.

        SB>
        SB> > +ScriptSock logs/cgisock
        SB>
        SB> We don't use mod_cgi in the mod_perl test suite. It's just a left-over
        SB> from testing. Does this patch fix things for you?
        SB>

        Nope, the patch had no effect whatsoever in the tests not failing.

        Regards,
        --
        Haroon Rafique
        <haroon.rafique@...>
      • Stas Bekman
        ... Sure, please find all the files that miss the end lines and post a patch fixing them, which will gladly apply and try to remember to keeping them in place
        Message 3 of 6 , Oct 1, 2003
        • 0 Attachment
          Haroon Rafique wrote:
          > On Today at 2:42pm, SB=>Stas Bekman <stas@...> wrote:
          >
          > SB> > Comments are welcome. And we really should have a newline at the end of
          > SB> > ModPerl-Registry/t/conf/extra.conf.in
          > SB>
          > SB> certainly, but does it break anything?
          > SB>
          >
          > Hi Stas,
          >
          > Doesn't break anything really, but when I was using the >> operator to
          > tack on some directives at the end of this file not having the newline
          > caused me some grief as the last line and my added line got stuck on the
          > same line (oops that makes it a misspelled directive - sheepish grin :-))

          Sure, please find all the files that miss the end lines and post a patch
          fixing them, which will gladly apply and try to remember to keeping them in
          place in the future.

          > SB> [...]
          > SB>
          > SB> > +SetEnv TMPDIR /tmp
          > SB>
          > SB> This is not a portable change. If you have a particular problem with
          > SB> regards to temp dir it needs to be solved where it arises (e.g. using
          > SB> File::Temp), but you don't tell what the problem is, so I can't give
          > SB> you a solution.
          >
          > I really should spend more time explaining the issue rather than jumping
          > to the solution. Thanks for listening. Here's the issue. As I mentioned
          > Gentoo's pacakge mgmt. system has the capability to build/install as a
          > non-root user. Somewhere down line during the tests, the following tests
          > are failing when run under the non-root user.
          >
          > modules/cgi....................NOK 3# Failed test 3 in modules/cgi.t at
          > line 41
          > modules/cgi....................FAILED test 3
          > Failed 1/5 tests, 80.00% okay
          > modules/cgiupload..............NOK 1# Failed test 1 in modules/cgiupload.t
          > at line 32
          > modules/cgiupload..............NOK 2# Failed test 2 in modules/cgiupload.t
          > at line 32 fail #2
          > modules/cgiupload..............FAILED tests 1-2
          > Failed 2/2 tests, 0.00% okay
          >
          > Looing at t/logs/error_log, we find:
          >
          > [Wed Oct 01 18:15:18 2003] [error] (13)Permission denied: Couldn't unlink
          > unix domain socket /var/run/cgisock
          > [Wed Oct 01 18:15:18 2003] [error] (98)Address already in use: Couldn't
          > bind unix domain socket /var/run/cgisock
          > ACCESS DENIED unlink: /var/run/cgisock
          >
          > As I mentioned earlier, the permissions for /var/run/cgisock are not
          > accissible by the non-root user. In addition, it is a violation of the
          > sandbox principle. My fix for ScriptSock was meant to appease mod_cgid
          > into creating the cgisock in the logs directory instead which will make it
          > self-contained and won't violate the sandbox.
          >
          > In the case of SetEnv TMPDIR /tmp, CGI.pm uses /tmp as its temporary
          > repository. Access to /tmp is again a violation of the sandbox. I agree
          > that /tmp is not a portable solution but setting TMPDIR is the only way
          > that I can think of to vary CGI.pm's behavior thru the httpd conf file.
          > Perhaps, a kludge like:
          > SetEnv TMPDIR logs
          > would suffice. I believe CGI.pm cleans up after itself anyway.

          I think you mix two to some extent unrelated problems together. Let's solve
          each problem apart.

          1) the three tests above are failing due to the /tmp problem in the sandbox,
          right? I believe your proposal of using the logs dir is cool. However we want
          to add a comment of why we do that (self-contained?) and I don't think it'll
          work without using a fullpath. So it probably should be:

          + # keep everything self-contained, to avoid problems with sandboxes
          + SetEnv TMPDIR @t_logs@

          running t/TEST -conf should expand @t_logs@ to its full path. To be consistent
          let's put it in both test suites and eventually we might merge it into
          Apache-Test so it'll do that by itself.

          Does it solve the problem with failing tests? If so please post a patch that
          works for you.

          Another alternative is to introduce a new directory for Apache-Test: t/tmp and
          a corresponding -tmp option to override the default, which is probably a
          cleaner solution in the long run.

          > SB>
          > SB> > +ScriptSock logs/cgisock
          > SB>
          > SB> We don't use mod_cgi in the mod_perl test suite. It's just a left-over
          > SB> from testing. Does this patch fix things for you?
          > SB>
          >
          > Nope, the patch had no effect whatsoever in the tests not failing.

          2) > [Wed Oct 01 18:15:18 2003] [error] (13)Permission denied: Couldn't unlink
          > unix domain socket /var/run/cgisock

          I'm trying to understand why do we have this problem when we don't use
          mod_cgid. Is it because mod_cgid gets loaded?

          but your patch sounds good to me. Again something to consider to merge into
          the Apache-Test autogenerator. In fact we should probably just do it. Will the
          following work:

          <IfModule mod_cgid.c>
          ScriptSock logs/cgisock
          <IfModule>



          __________________________________________________________________
          Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
          http://stason.org/ mod_perl Guide ---> http://perl.apache.org
          mailto:stas@... http://use.perl.org http://apacheweek.com
          http://modperlbook.org http://apache.org http://ticketmaster.com
        • Haroon Rafique
          On Today at 4:12pm, SB= Stas Bekman wrote:SB SB Sure, please find all the files that miss the end lines and post a SB patch fixing
          Message 4 of 6 , Oct 1, 2003
          • 0 Attachment
            On Today at 4:12pm, SB=>Stas Bekman <stas@...> wrote:

            SB>
            SB> Sure, please find all the files that miss the end lines and post a
            SB> patch fixing them, which will gladly apply and try to remember to
            SB> keeping them in place in the future.

            Really its no big deal. Just one file which is fixed in the attached
            patch.

            SB>
            SB> [...]
            SB>
            SB> + # keep everything self-contained, to avoid problems with sandboxes
            SB> + SetEnv TMPDIR @t_logs@

            Seems logical. Attached patch follows this theme.

            SB>
            SB> [...]
            SB>
            SB> Does it solve the problem with failing tests? If so please post a
            SB> patch that works for you.

            Yes, the patch fixes the failing tests/sandbox violations. Find attached.

            SB>
            SB> Another alternative is to introduce a new directory for Apache-Test:
            SB> t/tmp and a corresponding -tmp option to override the default, which
            SB> is probably a cleaner solution in the long run.

            All good ideas for the long run. Not familiar with Apache-Test, so can't
            comment.

            SB>
            SB> 2) > [Wed Oct 01 18:15:18 2003] [error] (13)Permission denied:
            SB> Couldn't unlink
            SB> > unix domain socket /var/run/cgisock
            SB>
            SB> I'm trying to understand why do we have this problem when we don't use
            SB> mod_cgid. Is it because mod_cgid gets loaded?

            Good question. Here's what I believe is happening. /usr/sbin/apxs2 is the
            path to my APache eXtenSion tool. During the conf generation process apxs2
            is used to figure out the location of the central config file for apache2
            (/etc/apache2/conf/apache2.conf). This file does have a:
            LoadModule cgid_module modules/mod_cgid.so
            line. References to cgid are then found abundantly in
            t/conf/apache_test_config.pm (another generated file). Finally, the
            following section appears in the generated file t/conf/httpd.conf:

            <IfModule !mod_cgid.c>
            LoadModule cgid_module "/etc/apache2/modules/mod_cgid.so"
            </IfModule>

            Should (and more importantly how do) we attempt to keep cgid out of the
            conf files?

            SB>
            SB> [...]
            SB>
            SB> <IfModule mod_cgid.c>
            SB> ScriptSock logs/cgisock
            SB> <IfModule>

            Attached patch uses the above lines as well.
            --
            Haroon Rafique
            <haroon.rafique@...>
          • Stas Bekman
            ... You get to break the 1.99_11-dev ice ;) Thanks, committed (with some more XXX noise, so we get this to polish later) ... I think you will want it in a
            Message 5 of 6 , Oct 1, 2003
            • 0 Attachment
              Haroon Rafique wrote:

              > Yes, the patch fixes the failing tests/sandbox violations. Find attached.

              You get to break the 1.99_11-dev ice ;) Thanks, committed (with some more XXX
              noise, so we get this to polish later)

              > SB>
              > SB> Another alternative is to introduce a new directory for Apache-Test:
              > SB> t/tmp and a corresponding -tmp option to override the default, which
              > SB> is probably a cleaner solution in the long run.
              >
              > All good ideas for the long run. Not familiar with Apache-Test, so can't
              > comment.

              I think you will want it in a short run as well (I mean the merging of your
              patches into the autogenerated httpd.conf), because all other Apache:: modules
              using Apache::Test will have the same issues. So the next time you encounter
              this knock again here so we get it into Apache-Test.

              > SB> 2) > [Wed Oct 01 18:15:18 2003] [error] (13)Permission denied:
              > SB> Couldn't unlink
              > SB> > unix domain socket /var/run/cgisock
              > SB>
              > SB> I'm trying to understand why do we have this problem when we don't use
              > SB> mod_cgid. Is it because mod_cgid gets loaded?
              >
              > Good question. Here's what I believe is happening. /usr/sbin/apxs2 is the
              > path to my APache eXtenSion tool. During the conf generation process apxs2
              > is used to figure out the location of the central config file for apache2
              > (/etc/apache2/conf/apache2.conf). This file does have a:
              > LoadModule cgid_module modules/mod_cgid.so
              > line. References to cgid are then found abundantly in
              > t/conf/apache_test_config.pm (another generated file). Finally, the
              > following section appears in the generated file t/conf/httpd.conf:
              >
              > <IfModule !mod_cgid.c>
              > LoadModule cgid_module "/etc/apache2/modules/mod_cgid.so"
              > </IfModule>

              That's right, it inherits from the global httpd.conf installed system-wide.

              > Should (and more importantly how do) we attempt to keep cgid out of the
              > conf files?

              Nuh, you gave us the fix, so we are all set ;)

              Thank you.

              __________________________________________________________________
              Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
              http://stason.org/ mod_perl Guide ---> http://perl.apache.org
              mailto:stas@... http://use.perl.org http://apacheweek.com
              http://modperlbook.org http://apache.org http://ticketmaster.com
            Your message has been successfully submitted and would be delivered to recipients shortly.