Re: [squid-dev] [RFC] Squid 4.0 ideas
The Foundation board has had a bit of discussion about this proposal during the last meeting and countered with a different proposal for consideration. Otherwise are split over whether to change at all, and with good reasons on all sides of he decision. Proposal 2) We are developing Squid with an incremental development process. The initial major version number is effectively meaningless in that process. We should move from the major.minor.patch to just a release.patch numbering system. This would mean this years upcoming major series would be 4.x, and next years would be 5.x and so on. There are quite a lot of infrastructure changes involved with that big a change, and its not entirely clear how the beta releases would be represented - perhapse not having any beta releases at all? Beta releases can be managed just like they are now: MAJ.0.X would be beta MAJ.Y (Y=1) would be stable If the issue of betas can be resolved in a good way I am inclined to go with proposal #2 myself. Lacking that with proposal #1. We still have a few months to think about this before a final call is made. All ideas and opinions welcome. +1. Guys, please speak up :) Kinkie ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
Re: [squid-dev] [PATCH] start workers as root
On 03/07/2015 07:18 AM, Amos Jeffries wrote: On 7/03/2015 12:18 a.m., Tsantilas Christos wrote: SMP workers in trunk start without root privileges. This results in startup failures when workers need to use a privileged port (e.g., 443) or other root-only features such as TPROXY. This bug added with my Moved PID file management from Coordinator to Master patch. The problem is inside watch_child function which called after a enter_suid() call, but the writePidFile() call, inside the watch_child(), will leave suid mode before exit. This patch removes the enter_suid/leave_suid cals from the writePidFile and make the caller responsible for setting the root privileges if required. I think this is wrong approach. Firstly, what are processes without SUID ability doing writing to secure system files? What do you mean here? Secondly, I thought the entire point of the earlier patch was to make the *MASTER* process was the one writing the PID file. Not low-privileged workers. Yes the master process writing the pid file, not the workers. Thirdly, the enter/leave_suid calls mean dangerous security stuff about to happen and should only be called if absolutely necessary, AND only around the (block of) system calls which require them. I agree. However the watch_child which is implements the master process, is designed to run in suid mode. This was not changed by the PID patch. Just due to a bug added with the PID patch this function leaves the suid mode. Maybe we want to fix master process to not run in suid mode, but I believe: - This is not a scope for this patch - The master process does not do a lot of thinks. Probably we do not need to make it run with low privileges. Moreover we may have problems with the kids. (Is it possible for kids to run with different cache_effective_user parameter?) Your description sounds like some part of the code in worker scope is using enter_suid doing a lot of Squid stuff - plus incidentally some root system stuff, then leave_suid. That is broken code. None of the general Squid stuff are security sentitive system calls needing root privileges. No, please forget the workers. This patch does not change anything in a worker. Please take a look into the writePidFile function, and into watch_child function (which implements the master process) We should be fixing that broken code. Either to not need the system suid privilege at all, or to call enter/leave_suid only around the sensitive operation - while also ensuring those suid calls will work at the point they are used. Amos ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
Re: [squid-dev] Moved PID file management from Coordinator to Master
I do not understand fully the patch but get the idea and since 3.5.2 is very stable for the public use as a simple forward proxy with ICAP and external_acl helpers it seems to that this patch will add for the stability of the 3.5 branch. I had a scenario of a development server testing which I needed to wait\kill couple times while not knowing how long it would take for the squid different instances to shutdown, and pgrep or ps aux|grep squid should not be something that will monitor squid. So: + 1 Eliezer On 06/03/2015 20:38, Alex Rousskov wrote: Amos, This patch went into trunk (r13867 and r13868). Do you plan on merging it (together with the pending start workers as root follow up) into v3.5 branch? It is your call, of course, but it is essentially a bug fix (SMP Squid does not restart reliably on busy servers without these changes). We can provide a v3.5-specific [combined] patch if that will make a positive decision easier for you. Thank you, Alex. ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
Re: [squid-dev] [PATCH] start workers as root
On 8/03/2015 6:34 a.m., Tsantilas Christos wrote:
On 03/07/2015 07:18 AM, Amos Jeffries wrote:
On 7/03/2015 12:18 a.m., Tsantilas Christos wrote:
SMP workers in trunk start without root privileges. This results in
startup failures when workers need to use a privileged port (e.g., 443)
or other root-only features such as TPROXY.
This bug added with my Moved PID file management from Coordinator to
Master patch.
The problem is inside watch_child function which called after a
enter_suid() call, but the writePidFile() call, inside the
watch_child(), will leave suid mode before exit.
This patch removes the enter_suid/leave_suid cals from the writePidFile
and make the caller responsible for setting the root privileges if
required.
I think this is wrong approach.
Firstly, what are processes without SUID ability doing writing to secure
system files?
What do you mean here?
After your patch that makes the master file the one writing the PID file
what are the workers (non-master) doing writing to it?
Secondly, I thought the entire point of the earlier patch was to make
the *MASTER* process was the one writing the PID file. Not
low-privileged workers.
Yes the master process writing the pid file, not the workers.
Thirdly, the enter/leave_suid calls mean dangerous security stuff about
to happen and should only be called if absolutely necessary, AND only
around the (block of) system calls which require them.
I agree.
However the watch_child which is implements the master process, is
designed to run in suid mode. This was not changed by the PID patch.
Just due to a bug added with the PID patch this function leaves the suid
mode.
I think I understand you there. You mean this process:
enter_suid()
...
watch_child()
...
writePidFile() {
enter_squid() // no-op
...
leave_suid()
}
... something that needs suid. oops.
Maybe we want to fix master process to not run in suid mode, but I believe:
- This is not a scope for this patch
- The master process does not do a lot of thinks. Probably we do not
need to make it run with low privileges. Moreover we may have problems
with the kids. (Is it possible for kids to run with different
cache_effective_user parameter?)
Yes, more than possible - probable that somebody will or is already
doing so. Just the other day I saw someone running workers with
different PID files.
Thats the kind of thing that happens with these directives available in
via squid.conf per-worker.
Your description sounds like some part of the code in worker scope is
using enter_suid doing a lot of Squid stuff - plus incidentally some
root system stuff, then leave_suid. That is broken code. None of the
general Squid stuff are security sentitive system calls needing root
privileges.
No, please forget the workers. This patch does not change anything in a
worker.
Please take a look into the writePidFile function, and into watch_child
function (which implements the master process)
The place your patch is changing are all in the workers code.
Instead of moving the enter_suid() outside of writePidFile() in several
places the master code should call enter only to preserve the part of
code *it* needs suid. eg.
watch_child()
...
writePidFile()
enter_suid(); // writePidFile() uses leave_suid()
...
Much simpler patch, and fewer places overall using enter/leave_suid.
Amos
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev
Re: [squid-dev] [RFC] Squid 4.0 ideas
On 20/10/2014 10:38 a.m., Amos Jeffries wrote: Kinkie brought up the idea of a Squid 4.x release in IRC. I have mentioned to a few clients who asked when 4.0 would be out that we will probably want it to be a big reason, like changing the language was between the 2.x to 3.x versions. I have usually had in mind a change along the lines of: - libraries building with Erlang/Ada/Go, or - redesigning the whole packaging structure (but we already have SourceLayout without it), or - redesigning the event processing system (but we already did AsyncJob without it). Then again, we actually *are* planning a language change in the next few months. Proposal 1) The C++03 to C++11 transition will bring with it a relatively large bump in the minimum toolchain and thus OS support. So while it's not a radical change it is probably worth considering as a good reason for calling the next series 4.0. If we do so we would also need to treat 3.5 as somewhat of an LTE (Sorry thats a typo, I meant LTS - Long Term Supported. With most of the support being by the distro maintainers, but upstream accepting compiler support patches in addition to security fixes in its EOL period) release. That was on the cards anyway for older OS with backports having the same criteria of building on C++03 compilers. The version bump would make it somewhat formal though with us needing to take on the maintenance instead of punting it off to commercial or distro support teams. Are we prepared as a group to go for that? The Foundation board has had a bit of discussion about this proposal during the last meeting and countered with a different proposal for consideration. Otherwise are split over whether to change at all, and with good reasons on all sides of he decision. Proposal 2) We are developing Squid with an incremental development process. The initial major version number is effectively meaningless in that process. We should move from the major.minor.patch to just a release.patch numbering system. This would mean this years upcoming major series would be 4.x, and next years would be 5.x and so on. There are quite a lot of infrastructure changes involved with that big a change, and its not entirely clear how the beta releases would be represented - perhapse not having any beta releases at all? If the issue of betas can be resolved in a good way I am inclined to go with proposal #2 myself. Lacking that with proposal #1. We still have a few months to think about this before a final call is made. All ideas and opinions welcome. Amos ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
