[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