Specify VCL path and load multiple files at once with vcl.load in cli

[walid-git]

This PR adds two features to vcl.load cli command:

• A "-p <vcl_path>" argument that is prepended to VLC_PATH parameter when loading the vcl.
• Specify multiple vcl files with a single vcl.load command.

In order to have a way to accept multiple files, we need to be able to accept any number of arguments (>2), but with the current implementation there will be a confusion for the last argument as there is no way to tell if it is a state (auto|cold|warm) or a VCL file. To address that, the first commit turns the state argument into an optional [-s auto|cold|warm] argument, and the second one does the same for vcl.inline for compliance.

The new format for vcl.load command is the following: vcl.load [-s auto|cold|warm] [-p vcl_path] <configname> <file1> [file2, ...]

[nigoroll]

quick bugwash notes:

• generally in favor
• let's not break vcl.load
• but rather add vcl.load_files [-s state] [-p path] <file> ...
• -p should be forbidden if vcl_path is protected

please do also add some more detailed documentation and changes.rst entry

[dridi]

Note: the pull request is currently failing deprecated persistent storage test cases in circleci, but with 53023a49ee4901e80 that has the feature jammed into vcl.load instead of a new vcl.load_files command tests are passing again.

We need to find what is causing this, but we weren't able to reproduce it locally.

[walid-git]

Thanks to @bsdphk 's commit 22f5e216fb22ef4ae17b877ed80a99dc090123ed, all the tests are now passing successfully. Reviews are welcome.

[dridi]

Bugwash: this triggered a CLI privilege discussion in need for an overview.

[walid-git]

Updated the doc to mention that -p fails when vcl_path is read only

[nigoroll]

bugwash: @bsdphk wants to finish a review of the CLI privilege design before making a decision on this ticket.

[dridi]

I found myself giving @walid-git to read what I still consider to date the best random outburst (ever since I first read it).

https://varnish-cache.org/docs/trunk/phk/barriers.html

Seeing the diagram, I noticed the ADMIN vs OPER distinction @bsdphk was making on IRC when we last discussed this. My claim was that this distinction was a bit too stringent, especially since our defaults require root privileges to read the CLI secret.

According to the diagram, the CLI actually is an admin privilege and the "mere" operator only has VSM access (and even that requires specific credentials with our defaults).

So overriding the vcl_path on a per-VCL basis can be done on the CLI, since CLI privileges are the same as varnishd -r privileges. I see no actual concern in this area, and I finally remember from where I got my interpretation of our security model.

[bsdphk]

This is on hold until we have agreed if the 2010 vintage security barriers are still the right one for us.

Input solicited, in particular on different "levels" of CLI access and how to determine which one to offer on a given connection.

[dridi]

bugwash: Varnish Software will collect security barriers requirements and submit them for discussion.

Note to self: #3729 should serve as input too.