On 30/01/2014 2:06 p.m., Alex Rousskov wrote: > On 01/29/2014 03:44 PM, Amos Jeffries wrote: >> On 2014-01-30 06:55, Alex Rousskov wrote: >>> The kid executable (e.g., disker, coordinator, worker, etc.) path is >>> already covered by the current Squid executable path. > >> What? >> Executable path as I understand it is in .../sbin/ usually. > > In this case, the kid executable path is argv[0] in Squid's main(). >
Exactly. /foo/sbin/ executable path has nothing to do with where the UDS socket goes. Squid is fork()'ing anyway so executable path is not even relevant to starting the kid processes. > >>> All others above (and more) can be covered with the following two >>> options, with reasonable defaults (which may include a service name >>> component), until we have a need for something more refined: >>> >>> shared_memory_dir >>> uds_dir >>> >>> Not bad, IMO! >>> >>> Furthermore, I think it is a good idea to eventually add a squid.conf >>> option to overwrite --prefix effects: >>> >>> root_dir >>> >> >> +1. > > Great. Please consider adjusting your pending patches to implement > shared_memory_dir and uds_dir (while adding "service name" to their > default values)? > You want service_name in the /path/ rather than the filename portion of the filepath ? > >> I was hoping chroot would double for that as you can probably tell >> from my past posts. Still do, but only if we can do that without >> breaking the chroot security properties. > > I agree with Henrik that chroot is pretty much irrelevant for the > purpose of this discussion. It requires root access and brings in many > other complications. The above "root_dir" directive, if somebody wants > to add it, would be free of all those headaches and considerations (and > will not add any protection, unlike chroot, of course!). It is just a > runtime --prefix. > Will do. Although "base_path" seems a little better for its name, to avoid implications of a link with chroot or root user. Amos
