Re: [RFC] Squid process model and service name impact

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Thu, 30 Jan 2014 17:01:43 +1300

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
Received on Thu Jan 30 2014 - 04:01:51 MST

This archive was generated by hypermail 2.2.0 : Fri Jan 31 2014 - 12:00:17 MST