1. 01 Dec, 2022 1 commit
  2. 27 Apr, 2022 4 commits
  3. 25 Jan, 2022 2 commits
  4. 26 Oct, 2021 1 commit
  5. 25 May, 2021 1 commit
  6. 23 May, 2021 2 commits
  7. 10 May, 2021 10 commits
    • Geoff Simmons's avatar
    • Nils Goroll's avatar
    • Nils Goroll's avatar
      Test that we capture stderr · 69d0f64a
      Nils Goroll authored
      69d0f64a
    • Nils Goroll's avatar
      Improve VDP_END handling · ae6c25d0
      Nils Goroll authored
      - ensure we do send VDP_END down
      - try to send it with the last bytes (POLLHUP present
        with a read smaller than the buffer size)
      ae6c25d0
    • Nils Goroll's avatar
      Test two pipe VDPs in a row · 0ac4b2d4
      Nils Goroll authored
      0ac4b2d4
    • Nils Goroll's avatar
      Close all file descriptors for the external program · d1c7d43c
      Nils Goroll authored
      ... except for stdin, stdout and stderr.
      
      Besides the obvious security issue, this avoids an issue where output
      processing would hang with more than one pipe vdp:
      
      When we see a VDP_END, we close the external program's stdin. Yet before
      we closed all file descriptors, a second external progam would also hold
      the stdin pipe's write end open.
      d1c7d43c
    • Nils Goroll's avatar
      No need to close file descriptors which we dup2() to · 937622d9
      Nils Goroll authored
      dup2() closes the destination file descriptor anyway
      937622d9
    • Nils Goroll's avatar
      The stdin filedescriptor needs to be non-blocking · 631443ec
      Nils Goroll authored
      Any real-world object will exceed the pipe buffer in size. Unless the
      filter program which we invoke implemented an infinite buffer (and
      requiring something like this would miss the point of stream
      processing), we can only write to the program as much data as it
      accepts for its input buffering (plus the pipe buffer size), before we
      need to read its output.
      
      Thus, we need to ensure that write(fds[STDIN_FILENO].fd) does not
      block.
      631443ec
    • Nils Goroll's avatar
      We may or may not have an objcore · dcc7f1be
      Nils Goroll authored
      Only the first filter has access to the objcore.
      
      fixes:
      
      Assert error in vdp_init(), vdfp_pipe.c line 189:
        Condition((objcore) != NULL) not true.
      version = varnish-trunk revision
      136736b092206c5bc764f12f80d9092efde6c9dc, vrt api = 13.0
      ident = Linux,5.10.12-200.fc33.x86_64,x86_64,-junix,-sfile,-sdefault,-hcritbit,epoll
      now = 3808647.356313 (mono), 1618849595.965169 (real)
      Backtrace:
        0x559444057399: /usr/sbin/varnishd(+0x57399) [0x559444057399]
        0x5594440ce273: /usr/sbin/varnishd(VAS_Fail+0x43) [0x5594440ce273]
        0x7fc6745f820f: ./vmod_cache/_vmod_pipe.f336a3498bf9765ce992b39693196344e9c1ddda789775d4d0b0fd3b4939272e(+0x220f) [0x7fc6745f820f]
        0x5594440381a3: /usr/sbin/varnishd(VDP_Push+0x103) [0x5594440381a3]
        0x55944406df96: /usr/sbin/varnishd(VCL_StackVDP+0x76) [0x55944406df96]
        0x55944405ce02: /usr/sbin/varnishd(+0x5ce02) [0x55944405ce02]
        0x55944405ec48: /usr/sbin/varnishd(CNT_Request+0xd8) [0x55944405ec48]
        0x559444088bbb: /usr/sbin/varnishd(+0x88bbb) [0x559444088bbb]
        0x55944407cee7: /usr/sbin/varnishd(+0x7cee7) [0x55944407cee7]
        0x55944407d494: /usr/sbin/varnishd(+0x7d494) [0x55944407d494]
      dcc7f1be
    • Nils Goroll's avatar
      vstrerror has been renamed to VAS_errtxt · 6663055d
      Nils Goroll authored
      6663055d
  8. 29 Apr, 2021 4 commits
  9. 20 Apr, 2021 7 commits
    • Nils Goroll's avatar
      Improve VDP_END handling · e16dc7b0
      Nils Goroll authored
      - ensure we do send VDP_END down
      - try to send it with the last bytes (POLLHUP present
        with a read smaller than the buffer size)
      
      Somehow related:
      
      - do not wait for the program to close stderr
      e16dc7b0
    • Nils Goroll's avatar
      Test two pipe VDPs in a row · 0b12aa09
      Nils Goroll authored
      0b12aa09
    • Nils Goroll's avatar
      Close all file descriptors for the external program · ba3d530a
      Nils Goroll authored
      ... except for stdin, stdout and stderr.
      
      Besides the obvious security issue, this avoids an issue where output
      processing would hang with more than one pipe vdp:
      
      When we see a VDP_END, we close the external program's stdin. Yet before
      we closed all file descriptors, a second external progam would also hold
      the stdin pipe's write end open.
      ba3d530a
    • Nils Goroll's avatar
      No need to close file descriptors which we dup2() to · 2b1c5d9a
      Nils Goroll authored
      dup2() closes the destination file descriptor anyway
      2b1c5d9a
    • Nils Goroll's avatar
      The stdin filedescriptor needs to be non-blocking · 71281335
      Nils Goroll authored
      Any real-world object will exceed the pipe buffer in size. Unless the
      filter program which we invoke implemented an infinite buffer (and
      requiring something like this would miss the point of stream
      processing), we can only write to the program as much data as it
      accepts for its input buffering (plus the pipe buffer size), before we
      need to read its output.
      
      Thus, we need to ensure that write(fds[STDIN_FILENO].fd) does not
      block.
      71281335
    • Nils Goroll's avatar
      We may or may not have an objcore · f64bdd40
      Nils Goroll authored
      Only the first filter has access to the objcore.
      
      fixes:
      
      Assert error in vdp_init(), vdfp_pipe.c line 189:
        Condition((objcore) != NULL) not true.
      version = varnish-trunk revision
      136736b092206c5bc764f12f80d9092efde6c9dc, vrt api = 13.0
      ident = Linux,5.10.12-200.fc33.x86_64,x86_64,-junix,-sfile,-sdefault,-hcritbit,epoll
      now = 3808647.356313 (mono), 1618849595.965169 (real)
      Backtrace:
        0x559444057399: /usr/sbin/varnishd(+0x57399) [0x559444057399]
        0x5594440ce273: /usr/sbin/varnishd(VAS_Fail+0x43) [0x5594440ce273]
        0x7fc6745f820f: ./vmod_cache/_vmod_pipe.f336a3498bf9765ce992b39693196344e9c1ddda789775d4d0b0fd3b4939272e(+0x220f) [0x7fc6745f820f]
        0x5594440381a3: /usr/sbin/varnishd(VDP_Push+0x103) [0x5594440381a3]
        0x55944406df96: /usr/sbin/varnishd(VCL_StackVDP+0x76) [0x55944406df96]
        0x55944405ce02: /usr/sbin/varnishd(+0x5ce02) [0x55944405ce02]
        0x55944405ec48: /usr/sbin/varnishd(CNT_Request+0xd8) [0x55944405ec48]
        0x559444088bbb: /usr/sbin/varnishd(+0x88bbb) [0x559444088bbb]
        0x55944407cee7: /usr/sbin/varnishd(+0x7cee7) [0x55944407cee7]
        0x55944407d494: /usr/sbin/varnishd(+0x7d494) [0x55944407d494]
      f64bdd40
    • Nils Goroll's avatar
      Close pipes when fork() fails · 63843ecb
      Nils Goroll authored
      63843ecb
  10. 28 Jan, 2021 1 commit
  11. 09 Dec, 2020 1 commit
  12. 16 Nov, 2020 1 commit
  13. 06 Oct, 2020 1 commit
  14. 15 Sep, 2020 1 commit
  15. 12 Aug, 2020 1 commit
  16. 11 Aug, 2020 2 commits
    • Geoff Simmons's avatar
      Document .setenv(). · 0c4b3341
      Geoff Simmons authored
      0c4b3341
    • Geoff Simmons's avatar
      Bugfix and extend .setenv(). · 723690f9
      Geoff Simmons authored
      Support the task-scoped invocation in vcl_deliver.
      
      Use a VSTAILQ for the setenv list. VSLIST pushes only to the head,
      so setenv() calls were in reverse order compared to the VCL calls.
      We want later invocations of .setenv() overwrite the value of previous
      invocations for the same variable (if overwrite is true). So use
      a tail queue and push to the tail.
      723690f9