Varnish jails, priv-sep, packaging etc.

Poul-Henning Kamp phk at
Wed Apr 15 13:45:34 CEST 2015

In message <CANTTouX0doF9BV++qWc-43UGdDto3E54kMLjWQF94GtE+71g4A at>
, "Rogier 'DocWilco' Mulhuijzen" writes:

>There's a case to be made for adding those admins to the varnish 
>group, but I don't think it's a big deal, as long as we nail down things
>within the directory.

That would make gid=varnish the general restrictor for acces, such that
it could also be used for VCL files etc.

>On the other hand, we could move the secret out of the directory, and use
>-n + _secret instead of -n + /_secret.

You can put the secret file wherever you like (and have as many copies
as you like) this is only about when people do not give a -S.

I think keeping it in the -n directory makes sense, and giving it the
same privs (uid/gid) as varnishd was started with is a good place to start.

>We write this before dropping privs, and don't need to read it at all,

Wrong, we need to read it to authenticate every single CLI connection.
(Remember you can change the content of the secret file on the fly
if you want), but the master can re-raise privs (and now does).

>        _.vsm           vadmin:varnish 644
>While we're on the subject of security, I don't think _.vsm should be world
>readable. There can be a ton of very valuable information in the VSM, like
>Cookie headers. Most of your email talks about the worker getting
>compromised, but you mentioned nobody. And there are possibly other
>processes running that are exposed to the outside world. Either because
>they talk to the network, or they are exposed through the world through

So 640 + vadmin:varnish ?

>And if we do that, making the directory 750 makes a little more sense too,
>since they already need to be in the group to do much useful things with

That would be consistent, but what does everybody else say ?

>I like using varnish for the vadmin part. Less change from a
>packaging/sysadmin perspective.


Dridi's suggestion of "vcache" is better than my "vrun".

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

More information about the varnish-dev mailing list