-------- In message <[email protected]>, Nils Goroll writes:
>* varnish should not require the file_chown/CAP_CHOWN (chown files owned by > other users) nor file_chown_self (solaris "giveaway") privileges. That is part of the problem I'm trying to resolve, I think my proposal allows us to do so without too much hazzle, simply because we can create the files after sandboxing, thereby getting the uid right from the start. >I think the varnishd master process (level#0) should continue to run as a >different $master_user (root) The master will run with the uid it started, whatever it is. >> -n directory: 755 $user:$group >> _.vsm 640 $user:$group_vsm (!feature::public_vsm) >> _.vsm 644 $user:$group_vsm (feature::public_vsm) >> _.secret 640 $user:$group >> vcl.*.c 660 $user:$group (temporary file) >> vcl.*.so 440 $user:$group > >$master_user (root) would not be able to open any of these files If your master process runs as root, it can setgroups itself into $group. >I suggest to have a configurable $vcc_dir [...] What for ? The increment of security is pointless IMO. >On 11/02/15 10:39, Poul-Henning Kamp wrote:> $group_cc >> Platform dependent group added to the CC subprocess for >> access to C-compiler bits. (default: empty) > >can you elaborate on this? Can you give an example what this is to be used for? >How would you "add" the group to the subprocess? See ad6bf9c0e51954cc45fee92d484e95c666d99685 and #1521 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [email protected] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ varnish-dev mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
