[Varnish] #912: Vanish lacks the file_read privilege on recent OpenSolaris

Varnish varnish-bugs at varnish-cache.org
Fri Sep 30 15:32:24 CEST 2011

#912: Vanish lacks the file_read privilege on recent OpenSolaris
 Reporter:  mamash        |        Owner:  slink 
     Type:  defect        |       Status:  closed
 Priority:  normal        |    Milestone:        
Component:  port:solaris  |      Version:  2.1.5 
 Severity:  major         |   Resolution:  fixed 
 Keywords:                |  

Comment(by Poul-Henning Kamp <phk@…>):

 (In [f837fbca893cc09458482c5283456bf8990aeee6]) Split solaris sandboxing
 out to a separate source file, and apply
 patch received from Nils Goroll <nils.goroll at uplex.de>

 - [e0ee2a2e69654a9df74aaf3dcadc9639659cf42b] adds the file_read
   privilege needed for onnv_140 and newer (see #912), but we also need
   the file_write privilege for stevedore access.

 - If available, keep sys_resource in the permitted/limited set to
   allow cache_waiter_ports to raise the process.max-port-events
   resource control (feature to be added later).

 - When starting varnish with euid 0 on Solaris, privilege seperation
   prohibited preserving additional privileges (in excess of the basic
   set) in the child, because, for a non privilege aware process,
   setuid() resets the effective, inheritable and permitted sets to the
   basic set.

   To achieve interoperability between solaris privileges and
   setuid()/setgid(), we now make the varnish child privilege aware
   before calling setuid() by trying to add all privileges we will need
   plus proc_setid.

 - On solaris, check for proc_setid rather than checking the euid as a
   prerequisite for changing the uid/gid and only change the uid/gid if
   we need to (for a privilege aware process, [ers]uid 0 loose their
   magic powers).

   Note that setuid() will always set SNOCD on Solaris, which will
   prevent core dumps from being written, unless setuid core dumps are
   explicitly enabled using coreadm(1M).

   To avoid setuid() (and the SNOCD flag, consequently), start varnish
   as the user you intend to run the child as, but with additional
   privileges, e.g. using

   ppriv -e -s A=basic,net_privaddr,sys_resource varnishd ...

 - setppriv(PRIV_SET, ...) failed when the privileges to be applied
   were not available in the permitted set.

   We change the logic to only clear the privileges which are not
   needed by inverting the sets and removing all unneeded privileges
   using setppriv(PRIV_OFF, ...).

   So the child might end up with less privileges than given initially,

Ticket URL: <https://www.varnish-cache.org/trac/ticket/912#comment:4>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator

More information about the varnish-bugs mailing list