Re: Patch for chroot() in 2.5STABLE1

Both approaches have their merits.

Being the author of the chroot_dir directive I may be slightly biased,
but what I'd really like to see for Squid is that chroot_dir is applied
after parsing the configuration file and referenced configuration data
(including SSL certificates for https_port) and writing of pid file, but
before checking paths to helpers etc..

For security reasons I do not want to have configuration data within the
chroot jail, and on a SSL enabled Squid SSL certificates and keys
certainly should not need to be within the chroot jail.

Regards
Henrik

Andrew Rucker Jones wrote:
>
> Hi everybody!
> Don't know if i managed to get subscribed to the list, but i'll try
> posting. :)

You managed.. even if you did not exacly follow the protocol, but close
enoght.

> Primary disadvantage of the old chroot() method: The configuration file
> was parsed before doing a chroot(), so many files and directories had to
> be mirrored both inside of the chroot() jail and outside. It is also
[...]
>
> Disadvantages of the new method (which uses a command line switch and
> immediately performs the chroot):
[...]

and less secure as all configuration data needs to be available within
the jail.

> Besides that, i fixed the spelling and grammar errors i ran across, and
> i took out the part in the man page about reading the FAQ that comes
> with the distribution, because the FAQ doesn't seem to come with the
> distribution anymore (or i'm blind).

I'll ltry to ook into these in the weekend, unless someone else beats me
to it.

the FAQ has never been part of the distribution (perhaps should, but
that is another question).

> Two small points about the Squid Web pages:
> http://www.squid-cache.org/Devel/ includes a reference to
> squid-dev-request@squid-cache.org, but it needs to be
> squid-dev-subscribe@squid-cache.org.

Should have a reference to mailing-lists.html me thinks..

> http://www.squid-cache.org/Devel/guidelines.html claims that indent
> should be run with the options -npsl AND -psl. Somehow i doubt it,
> unless i'm misreading the indent man page.

Well.. it is the options we use.. but this is only of concern to the
core developers. Other developers only need to make sure they roughtly
follow the style of the existing code and produces clean patches with
only their changes.. running indent is "dangerous" as it may easily end
up reformatting other code making it almost impossible to diff the
changes.

> Finally, is there still interest in finding an SNMP maintainer? I would
> be interested in being that person, but i make no promises yet. Just
> seeing if there's still a need.

Sure. It is an area not being actively looked after, only patched up as
needed. There is several errors and shortcomings in the SNMP
implementation, and I am sure there is many interesting values that
cannot be read via SNMP at the moment..

There is also a great need to integrate with system SNMP agents where
possible. Many NMS systems have trouble monitoring odd SNMP ports.

Regards
Henrik
Received on Thu Oct 03 2002 - 14:19:56 MDT