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

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.
Received on Thu Jan 30 2014 - 21:56:07 MST