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

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