On 01/29/2014 09:01 PM, Amos Jeffries wrote: > 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. In a long list of things that may need to become configurable, you said that disker path may need to become configurable. I said that it is already configurable (because it is the same as the current executable path); no new option is needed for that unless we decide to support non-Squid kids (which I hope we will not). Now you are talking about UDS sockets having no relation to kids executable path. I agree! UDS sockets was a different item on the same long list, and I did not mention UDS when discussing disker paths (I hope). As for forking, we actually use execvp() to start kids, with the current executable path (literally argv[0]) as the first parameter. Fork is used for daemonization. It would be possible to stuff a different executable path when calling execvp() but, again, I hope we will not decide to add support for that. >>>> 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 ? IMHO, using a service_name in the filename component would be easier for admins (they would need to create fewer directories) and backward compatible in some cases (where we already use the word "squid" in the file name; e.g., PID file name). Most file names would become longer and directory contents would become "messier" when multiple services are used, but perhaps that is not important? I do not have a strong preference or in-depth knowledge about service names and their use. You may want to ask folks that want to use service names... >>> 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. Please use _dir or _directory suffix to remain consistent with the existing squid.conf directive names: > NAME: cache_dir > NAME: store_dir_select_algorithm > NAME: coredump_dir > NAME: icon_directory > NAME: error_directory There are currently no directives with _path AFAIK (unless you count capath= option to the *_port directives). I know other projects are using PROJECT_ROOT for this kind of thing. "Root" feels "standard" for this purpose to me, so I think it would be better to use "root" rather than HTML-ish "base" despite the chroot() similarity, but I do not have a strong preference or in-depth knowledge about this subject. I am guessing chroot would apply first and root_dir second. In other words, chroot /foo root_dir /bar would mean that Squid will use /foo/bar/* paths by default, from the OS point of view. Please note that I am not asking you to add root_dir -- it is clearly outside your project scope and will probably open another can of worms such as its relationship with chroot() dir! Cheers, Alex.
