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(). >> 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)? > 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. >> I have also heard from folks that wanted to place either IPC socket >> files or shared memory segment handlers in a special directory that >> their appliance designated for such things (with the right permissions, >> SELinux capabilities, etc.). >> > > Okay. I had not heard that one being brought up yet. Thank you. > > Do you have any knowledge whether that differs from the "run" debate > (/var/run vs. /run vs. /tmp/run vs. /opt/run mounting point) between the > major OS FHS implementers? Sorry, no. I am not even familiar with that debate itself. Alex.
