ipcop-devel Mailing List for IPCop Firewall

On Tue, May 31, 2005 at 01:44:01PM +0200, Franck Bourdonnec wrote:
> Le Mardi 31 Mai 2005 13:33, Alan Hourihane a =E9crit :
> > Update of /cvsroot/ipcop/ipcop/lfs
> > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv23492
> >
> > Modified Files:
> > 	configroot
> > Log Message:
> > bring over from 1.4.0 branch
> >
> >
>=20
> Alan,
>  I was waiting to update this file.
>=20
> You did not answer to me about inserting lang files
> from addon.
> It's now far from first version, I discussed with Robert & Achim
> about it.
>=20
> I used it every day and it is much more easier to modify
> my addon lang file for squidguard than editing twice
> (source file for addon & fr.pl). I just move my file after
> editing and it's ok.
>=20
> You must get Langs.pl also.

Feel free to keep things in sync for the moment.

Alan.

Le Mardi 31 Mai 2005 13:33, Alan Hourihane a =E9crit :
> Update of /cvsroot/ipcop/ipcop/lfs
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv23492
>
> Modified Files:
> 	configroot
> Log Message:
> bring over from 1.4.0 branch
>
>

Alan,
 I was waiting to update this file.

You did not answer to me about inserting lang files
from addon.
It's now far from first version, I discussed with Robert & Achim
about it.

I used it every day and it is much more easier to modify
my addon lang file for squidguard than editing twice
(source file for addon & fr.pl). I just move my file after
editing and it's ok.

You must get Langs.pl also.

=46ranck

Jon

You may work with Geode fine. No extra need for patches etc.

I use industrial cards from ICP for firewalls, mainly ISS-102 (3
eths), see here for specs:
http://www.icp-australia.com.au/DataSheets/iss102.html
with both IPCOP and Smoothwall working perfectly. I buy from
http://www.icp-uk.com/ (delivery 2-4 weeks).

I have used 300Mhz and 233Mhz models. I use 64/128/256 Mb RAM, 1.5M of
which is reserved for the embedded VGA. The extra bonus is that you
have natural cooling, so if you use flash for IPCOP, you end up with a
closed box with no moving parts, no dust - very high reliability...

I also tested proxy capabilities which work fine for a couple PCs and
servers in a home or small office installation. But if you have 10 or
50 users use a faster cpu or disable proxy.

I use GEODE 300 with 128Mb routing 17 users, plus 3 servers through
adsl (192/512) with no problem (no proxy). I monitor my internal
users/servers with ntop. Sometimes you get slow response in the web
interface (e.g. firewall logs), but the routing/nat job is always
fast! Cpu usage is 3 - 6%. I even was running Seti@home in it, but the
FPU in GEODE is aufully slow (2.5 days a packet) so i stopped it!

If you install extra packages, always use the generic 386 flavor (not
the 586/686).

Hope i helped.
--=20
73's
Dimitri - SV1LL

On 5/30/05, jonr <jo...@de...> wrote:
> I thought I had saw where this processor was to be supported but can't
> seem to find what I thought I saw. I like to use the Soekris Net4801
> boxes but they use the Geode procs, is this processor supported by IPCop
> natively now or will I still need to patch myself?

On Tue, May 31, 2005 at 12:30:00PM +0200, Franck Bourdonnec wrote:
> Le Mardi 31 Mai 2005 12:21, vous avez =E9crit :
> > On Tue, May 31, 2005 at 12:08:14PM +0200, Franck Bourdonnec wrote:
> > > Le Mardi 31 Mai 2005 10:34, Alan Hourihane a =E9crit :
> > > > On Thu, Apr 28, 2005 at 11:18:43PM +0000, Franck Bourdonnec wrote=
:
> > > > > Update of /cvsroot/ipcop/ipcop/src/rc.d
> > > > > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21731
> > > > >
> > > > > Modified Files:
> > > > >       Tag: IPCOP_v1_4_0
> > > > > 	rc.netaddress.up
> > > > > Log Message:
> > > > > dnsmasq   was launched twice, useless
> > > >
> > > > Franck,
> > > >
> > > > You've moved dnsmasq to start only when AUTOCONNECT is off. Now, =
when
> > > > IPCop boots and it can't connect to the internet for some reason =
you
> > > > lose all local DNS services. That's not good.
> > > >
> > > > Can you reverse the dnsmasq part please, or come up with another =
fix
> > > > for what you were intending to do.
> > > >
> > > > Alan.
> > >
> > > Intention was to avoid lauching twice the program.
> >
> > Where was it launced twice ??
> >
> > Alan.
>=20
> in rc.netaddress.up then=20
> almost immediatly in rc.update.red

No, it isn't.=20

dnsmasq is killed before restarting it.

If you saw dnsmasq starting twice, then we should remove the 'sleep 1'
and do 'ps ax | grep dnsmasq' or somthing like that to check that it's
died.

Alan.

On Tue, May 31, 2005 at 12:08:14PM +0200, Franck Bourdonnec wrote:
> Le Mardi 31 Mai 2005 10:34, Alan Hourihane a =E9crit :
> > On Thu, Apr 28, 2005 at 11:18:43PM +0000, Franck Bourdonnec wrote:
> > > Update of /cvsroot/ipcop/ipcop/src/rc.d
> > > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21731
> > >
> > > Modified Files:
> > >       Tag: IPCOP_v1_4_0
> > > 	rc.netaddress.up
> > > Log Message:
> > > dnsmasq   was launched twice, useless
> >
> > Franck,
> >
> > You've moved dnsmasq to start only when AUTOCONNECT is off. Now, when
> > IPCop boots and it can't connect to the internet for some reason you
> > lose all local DNS services. That's not good.
> >
> > Can you reverse the dnsmasq part please, or come up with another fix
> > for what you were intending to do.
> >
> > Alan.
> >
> Intention was to avoid lauching twice the program.=20

Where was it launced twice ??

Alan.

Le Mardi 31 Mai 2005 10:34, Alan Hourihane a =E9crit :
> On Thu, Apr 28, 2005 at 11:18:43PM +0000, Franck Bourdonnec wrote:
> > Update of /cvsroot/ipcop/ipcop/src/rc.d
> > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21731
> >
> > Modified Files:
> >       Tag: IPCOP_v1_4_0
> > 	rc.netaddress.up
> > Log Message:
> > dnsmasq   was launched twice, useless
>
> Franck,
>
> You've moved dnsmasq to start only when AUTOCONNECT is off. Now, when
> IPCop boots and it can't connect to the internet for some reason you
> lose all local DNS services. That's not good.
>
> Can you reverse the dnsmasq part please, or come up with another fix
> for what you were intending to do.
>
> Alan.
>
Intention was to avoid lauching twice the program.=20
I move it 'as before' .
=46ranck

On Thu, Apr 28, 2005 at 11:18:43PM +0000, Franck Bourdonnec wrote:
> Update of /cvsroot/ipcop/ipcop/src/rc.d
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21731
> 
> Modified Files:
>       Tag: IPCOP_v1_4_0
> 	rc.netaddress.up 
> Log Message:
> dnsmasq   was launched twice, useless

Franck,

You've moved dnsmasq to start only when AUTOCONNECT is off. Now, when
IPCop boots and it can't connect to the internet for some reason you
lose all local DNS services. That's not good.

Can you reverse the dnsmasq part please, or come up with another fix
for what you were intending to do.

Alan.

> ipsecctrl was launched twice, useless
> May be a correction to sf bug 1177572, let only 'update.red' starts VPN
> when RED is up.
> 
> 
> Index: rc.netaddress.up
> ===================================================================
> RCS file: /cvsroot/ipcop/ipcop/src/rc.d/rc.netaddress.up,v
> retrieving revision 1.7.2.10
> retrieving revision 1.7.2.11
> diff -C2 -d -r1.7.2.10 -r1.7.2.11
> *** rc.netaddress.up	4 Apr 2005 19:41:57 -0000	1.7.2.10
> --- rc.netaddress.up	28 Apr 2005 23:18:40 -0000	1.7.2.11
> ***************
> *** 24,36 ****
>   fi
>   
> - # Start VPN Connections
> - /usr/local/bin/ipsecctrl S
> - 
> - # Start DNSMASQ with defaults
> - if [ "$DOMAIN_NAME_GREEN" == "" ]; then
> - 	/usr/sbin/dnsmasq -l /var/state/dhcp/dhcpd.leases
> - else 
> - 	/usr/sbin/dnsmasq -l /var/state/dhcp/dhcpd.leases -s "$DOMAIN_NAME_GREEN"
> - fi
>   
>   # If RED is ethernet then check furthur...
> --- 24,27 ----
> ***************
> *** 42,47 ****
>   fi
>   
> ! # Only when AUTOCONNECT is off, do we not bother dialing
> ! if [ "$AUTOCONNECT" != "off" ]; then
>   	/etc/rc.d/rc.red start
>   fi
> --- 33,50 ----
>   fi
>   
> ! # Only when AUTOCONNECT is off, do we not bother dialing but start local dns server
> ! if [ "$AUTOCONNECT" == "off" ]; then
> ! 	# Start VPN Connections         # bug 1177572 might be corrected because this
> ! 	# /usr/local/bin/ipsecctrl S    # call was done to much earlier (before RED start)
> ! 					# Presently commented because I'm not sure VPN is usefull without RED
> ! 
> ! 	# Start DNSMASQ with defaults
> ! 	if [ "$DOMAIN_NAME_GREEN" == "" ]; then
> ! 		/usr/sbin/dnsmasq -l /var/state/dhcp/dhcpd.leases
> ! 	else 
> !     		/usr/sbin/dnsmasq -l /var/state/dhcp/dhcpd.leases -s "$DOMAIN_NAME_GREEN"
> ! 	fi
> ! 
> ! else
>   	/etc/rc.d/rc.red start
>   fi
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Tell us your software development plans!
> Take this survey and enter to win a one-year sub to SourceForge.net
> Plus IDC's 2005 look-ahead and a copy of this survey
> Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
> _______________________________________________
> IPCop-cvs mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-cvs

Le Mardi 31 Mai 2005 02:29, Franck Bourdonnec a =E9crit :
> Le Lundi 30 Mai 2005 22:43, Marco Sondermann a =E9crit :
> > Hi,
> >
> > I've used the DHCP option 'wpad' (Web Proxy Auto Discovery) since IPCop
> > 1.4.0 up to 1.4.5, but this doesn't work anymore for 1.4.6:
> >
> >    option wpad "http://192.168.31.254:81/proxy.pac\n";
> >
> > Even adding the line
> >
> >    option wpad string;
> >
> > to the file advoptions-list doesn't fix it.
> >
> > Any chance to get it working again for IPCop 1.4.7 ?
> >
> > TIA, Marco
>
> Hello,
> Before 1.4.6 you were editing manually dhcpd.conf
> and all was ok.
>
> Now you use new facility to add same line.
> and it doesn't work.
>
> Strange because wpad is unknown form dhcpd program.
>
> But release 3.02 pemits new option defined like that:
>
> #define a new option
> option my_wpad code 252 =3D string;
> #then use it
> option my_wpad "http://192.168.31.254:81/proxy.pac";
>
> Older version of dhcpd allowed syntax:
> option option-252 "string";
>
> Ipcop can't accept yet the first syntax, sorry.
>
> Franck
>


Precision: the new definition must be at global level in dhcp conf.
but can be scoped latter.

I will adapt dhcp.cgi to accept this syntax.

=46ranck

Le Lundi 30 Mai 2005 22:43, Marco Sondermann a =E9crit :
> Hi,
>
> I've used the DHCP option 'wpad' (Web Proxy Auto Discovery) since IPCop
> 1.4.0 up to 1.4.5, but this doesn't work anymore for 1.4.6:
>
>    option wpad "http://192.168.31.254:81/proxy.pac\n";
>
> Even adding the line
>
>    option wpad string;
>
> to the file advoptions-list doesn't fix it.
>
> Any chance to get it working again for IPCop 1.4.7 ?
>
> TIA, Marco


Hello,
Before 1.4.6 you were editing manually dhcpd.conf
and all was ok.

Now you use new facility to add same line.
and it doesn't work.

Strange because wpad is unknown form dhcpd program.

But release 3.02 pemits new option defined like that:

#define a new option
option my_wpad code 252 =3D string;
#then use it
option my_wpad "http://192.168.31.254:81/proxy.pac";

Older version of dhcpd allowed syntax:
option option-252 "string";

Ipcop can't accept yet the first syntax, sorry.
=20
=46ranck

Hi,

I've used the DHCP option 'wpad' (Web Proxy Auto Discovery) since IPCop 
1.4.0 up to 1.4.5, but this doesn't work anymore for 1.4.6:

   option wpad "http://192.168.31.254:81/proxy.pac\n";

Even adding the line

   option wpad string;

to the file advoptions-list doesn't fix it.

Any chance to get it working again for IPCop 1.4.7 ?

TIA, Marco 

I thought I had saw where this processor was to be supported but can't 
seem to find what I thought I saw. I like to use the Soekris Net4801 
boxes but they use the Geode procs, is this processor supported by IPCop 
natively now or will I still need to patch myself?

Thanks for any help,

Jon

----- Original Message ----- 
From: <745...@to...>
To: <ipc...@li...>
Sent: Sunday, May 29, 2005 11:42 PM
Subject: [IPCop-devel] roadmap to IPCop 1.5?


> I have looked at the roadmap and tried to look in the list archives, but I
haven't found a roadmap that contained a timeline.  Does such a thing exist?
>
No. Usual answer is when it will be ready even we all hope it will be not
too fare away.

> I am curious if/when the 1.4 development will end, and the 1.5 development
begin.    Or is 1.5 already in development?
>
Yes v1.5 development has started but is in early stage

> Also, will the 1.5 series be based on the 2.6 kernel?  I'm having issues
with a Dlink DSB 650 usb to ethernet adapter, and I'd like to see if the
issue goes away with a 2.6 kernel.
>
Yes

Gilles

I have looked at the roadmap and tried to look in the list archives, but I haven't found a roadmap that contained a timeline.  Does such a thing exist?

I am curious if/when the 1.4 development will end, and the 1.5 development begin.    Or is 1.5 already in development?

Also, will the 1.5 series be based on the 2.6 kernel?  I'm having issues with a Dlink DSB 650 usb to ethernet adapter, and I'd like to see if the issue goes away with a 2.6 kernel.

Thanks.

Todd

Feature Requests item #1209991, was opened at 2005-05-27 16:10
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=1209991&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Submitted By: AndyLawn (andylawn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Block outbound traffic via the GUI

Initial Comment:
The GUI should include an interface to set up rules for 
blocking outbound traffic, for example similar to the 
BlockOutTraffic add-on.

I was surprised to find that IPCop does not offer this out 
of the box, it seems such a basic piece of firewall 
functionality.
Yes I could manually edit the iptables configuration but 
that's IPCop's great usability out of the window.
Yes I could install BOT but do I really want to install 
unsupported 3rd party add-ons on a production box?  
This is something that really ought to be incorporated in 
IPCop itself.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=1209991&group_id=40604

Feature Requests item #1209938, was opened at 2005-05-27 08:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=1209938&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Scott Silva (scottsilva)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pop proxy and antivirus

Initial Comment:
A pop proxy with a virus scanner would be great.
Maybe even run squid with antivirus if possible.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=1209938&group_id=40604

> addon-land dir perms:
> ipcop install script (lfs/configroot) uses
> noboby:nobody by default. I just reduce
> to readonly.

[...]

> > root:root 444 is enough. Why use less restricted settings when more
> > restricted settings do work too. And root:root is working.
> if it's better, ok
> it's hard to accept that "other=read" is better than "nobody=read"
> so it's certainly the "better to have owner=root" affirmation .

I'm no Unix permission guru, but I think when the owner is nobody, nobody
can
change the permissions (give himself the write permission). When the owner
ist root, nobody can't get write permissions.
What's wrong with "other=read"? There is no password or something else
stored
in the cachefile ;-)

> > I have written a description how to add own lang files into my script
which
> > writes this description to the cache file as a comment. When i updated
the
> > paths in the script yesterday, i forgot to update the
description/comment
> > aswell. Will update it today.
>
> Imagine your are new developper. You will explore ipcop, find '/var/ipcop'
> find /home/httpd/cgi-bin', find the 'lang dir' 'addon-lang' dir, etc....
> I think each ipcop lang file can have your comment added. Temptation is
> high to directly edit "en.pl" !

ok.

> Langs.pl also
> Cachefile have to be 'perl readeable' only.

Why, are there stored passwords?

> We have to agree on one thing : developpers must provide something
> that conforms to strict rules:

> -places files in ipcop/addon-lang dir
> -perms is root:root 444
> -one file per language. English (en) mandatory.
> -naming is "YourAddonNane.en.pl", "YourAddonName.xx.pl",  xx=country code
> (fr,it,....)
> -file content is of this form:
> %tr=(%tr,
> 	'pfx_key1' => 'key1 text',
> 	'pfx_key2' => 'key2 text',
> );
> -You must use %tr
> -You may prefix all your keys to avoid overwriting Ipcop's base key list.
> -Your addon can use Ipcop existing keys (see in langs/en.pl).

> And he must try addon before release !

ok

Achim

-- 
5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
+++ GMX - die erste Adresse für Mail, Message, More +++

Le Vendredi 27 Mai 2005 08:11, Achim Weber a =E9crit :

addon-land dir perms:
ipcop install script (lfs/configroot) uses
noboby:nobody by default. I just reduce
to readonly.


> > >But they are people who can do misstakes. If there is a simple
> > >solution to avoid this issue why not using it??
>
> Have you looked into my script?? You don't want to use this simple soluti=
on
> (writing/copy %tr to an extra hash)? tstststs :-(
Yes.
All %tr=3D(%tr,=20
are useless because you read an intermediate array ;-)
It's beautifull, easy to read, modular, This has a cost while in
'developper mode' (no cache file to test translation).=20

> I ask you again, why do you not want to use a simple code which avoids an
> issue you know of. One faulty lang file (missing "=3D(%tr,..." ) will bre=
ak
> the cache file. The developer may forgot this %tr or it got lost somewher=
e.
> Again a low-brow user will not know what to do when he enters the webgui
> and has no menu, button text, etc..
> Too why do you not want to write a clearly arranged cache file, you only
> need to "sort" the keys and add a "\n" at the end of each line. It's
> nice/friendly coding style me thinks.

I think it's better to be radical with developper. Imagine he mistakenly
hit a '  in one of it's "pl". It then switches to another cgi page + another
"pl" for this page (yes the guy love files: one cgi=3D> one "pl"  ;-) ).
He will never see the problem until someone says him "hey there is
no text on this page..." . But if Ipcop reports immediatly, distributing
broken addon is hardder !
=20

> maybe he don't want to overwrite it, but haven't seen the existing key. ;=
=2D)
so, he just have to conform to prefixing suggestion !

> root:root 444 is enough. Why use less restricted settings when more
> restricted settings do work too. And root:root is working.
if it's better, ok
it's hard to accept that "other=3Dread" is better than "nobody=3Dread"
so it's certainly the "better to have owner=3Droot" affirmation .=20
=20
Unix perms are so basic compared to novell+nds ;-)


> I have written a description how to add own lang files into my script whi=
ch
> writes this description to the cache file as a comment. When i updated the
> paths in the script yesterday, i forgot to update the description/comment
> aswell. Will update it today.
>
> Achim
Imagine your are new developper. You will explore ipcop, find '/var/ipcop'
find /home/httpd/cgi-bin', find the 'lang dir' 'addon-lang' dir, etc....
I think each ipcop lang file can have your comment added. Temptation is
high to directly edit "en.pl" !
Langs.pl also
Cachefile have to be 'perl readeable' only.


We have to agree on one thing : developpers must provide something
that conforms to strict rules:

=2Dplaces files in ipcop/addon-lang dir
=2Dperms is root:root 444
=2Done file per language. English (en) mandatory.
=2Dnaming is "YourAddonNane.en.pl", "YourAddonName.xx.pl",  xx=3Dcountry co=
de=20
(fr,it,....)
=2Dfile content is of this form:
%tr=3D(%tr,
	'pfx_key1' =3D> 'key1 text',
	'pfx_key2' =3D> 'key2 text',
);
=2DYou must use %tr
=2DYou may prefix all your keys to avoid overwriting Ipcop's base key list.
=2DYour addon can use Ipcop existing keys (see in langs/en.pl).

And he must try addon before release !

=46ranck

hi ..
i m beginer to IPCop,
i installed ipcop and begin testing , but ping is very slow and AWs
can not be opened , can any one please help me..

> ipcop/addon-lang  dir:
> 
> normal ipcop setup (lfs/configroot) installs "dirs" with=20
> nobody:nobody 755
> All data in thoses dirs are read with "readhash" &
> written with writehash.
> In this case, it should not be writtable. only httpd(nobody) needs
> reading. Prevent code injection by 'installing' new .pl file.
> 
> I really don't know what is best
> root:root 555
> nobody:nobody 550

root:root 555 is enough less restricted access (i.e. owner nobody) is not
neccessary. The ipcop lang files are root:root too (not sure with
permissions).

Not sure if lang.pl code is working with root:root 550. With a root script
no problem, i have set those permissions in my testbox an can run my script
fine.
 
> >But they are people who can do misstakes. If there is a simple
> >solution to avoid this issue why not using it??
> >
> >We know about the issue and don't use the simple solution
> > --> _very_ bad code/decision!
> 
> During installation of an addon-on, here, it it possible to
> provide super high level interface. Why not. But remember
> when you developp or translate. You work on the file with
> final format. If errors like missing " ' " immediate result=3D>
> httpd error !
> 
> I also want the things with the less unneeded checking while
> standart ipcop operation.

Have you looked into my script?? You don't want to use this simple solution
(writing/copy %tr to an extra hash)? tstststs :-(

I ask you again, why do you not want to use a simple code which avoids an
issue you know of. One faulty lang file (missing "=(%tr,..." ) will break
the cache file. The developer may forgot this %tr or it got lost somewhere.
Again a low-brow user will not know what to do when he enters the webgui and
has no menu, button text, etc..
Too why do you not want to write a clearly arranged cache file, you only
need to "sort" the keys and add a "\n" at the end of each line. It's
nice/friendly coding style me thinks.


> This is an 'intermediate level' where you can develop your add-on
> without complication. Erase the cachefile, and your changes on
> your lang file take effect immediatly.
> 
> About reading a third time with "en"
> Suggestion to developpers is (would)
> prefix  lang entries to avoid overwriting.

Have never said about reading "en" file a second or a third time. Read every
file only once.

> If a developper wants to overwrite, well, it is
> his choice.

maybe he don't want to overwrite it, but haven't seen the existing key. ;-)

> The cachefile: only httpd needs read it
> root:root 444
> nobody:nobody 440
> best  is ? Why ?

root:root 444 is enough. Why use less restricted settings when more
restricted settings do work too. And root:root is working.
 
> Perl call:
> perl -e "require '/var/ipcop/lang.pl';  &Lang::BuildCacheLang"
> 
> Don't you want to start writing a document for developper:
> =A71: adding language file to ipcop
> =A72: adding menus.....

I have written a description how to add own lang files into my script which
writes this description to the cache file as a comment. When i updated the
paths in the script yesterday, i forgot to update the description/comment
aswell. Will update it today.

Achim


-- 
Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie!
Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl

Le Jeudi 26 Mai 2005 19:03, Achim Weber a =E9crit :
> [...]

ipcop/addon-lang  dir:

normal ipcop setup (lfs/configroot) installs "dirs" with=20
nobody:nobody 755
All data in thoses dirs are read with "readhash" &
written with writehash.
In this case, it should not be writtable. only httpd(nobody) needs
reading. Prevent code injection by 'installing' new .pl file.

I really don't know what is best
root:root 555
nobody:nobody 550


>But they are people who can do misstakes. If there is a simple
>solution to avoid this issue why not using it??
>
>We know about the issue and don't use the simple solution
> --> _very_ bad code/decision!

During installation of an addon-on, here, it it possible to
provide super high level interface. Why not. But remember
when you developp or translate. You work on the file with
final format. If errors like missing " ' " immediate result=3D>
httpd error !

I also want the things with the less unneeded checking while
standart ipcop operation.
This is an 'intermediate level' where you can develop your add-on
without complication. Erase the cachefile, and your changes on
your lang file take effect immediatly.

About reading a third time with "en"
Suggestion to developpers is (would)
prefix  lang entries to avoid overwriting.
If a developper wants to overwrite, well, it is
his choice.

The cachefile: only httpd needs read it
root:root 444
nobody:nobody 440
best  is ? Why ?

Perl call:
perl -e "require '/var/ipcop/lang.pl';  &Lang::BuildCacheLang"

Don't you want to start writing a document for developper:
=A71: adding language file to ipcop
=A72: adding menus.....


=46ranck

[...]

>> > With actual permissions, two mode can be used
>> > with or whitout cachefile.
>> > Only root can create remove it.
>>
>> No, the owner of "addon-lang" dir is still nobody! This needs to be
>> corrected.
>>
>> root@ipcop147cvs:/var/ipcop # ls -al | grep addon-lang
>> drwxr-xr-x   2 nobody nobody  1024 2005-05-26 14:15 addon-lang
>>
>> > the "addonlang" dir must be only readeable.
>> >
>> > What needs to be validated is that 'someone'
>> > cannot add a lang file and remove the=20
>> > cachefile (ie injection).
>>
>> jep, the cache file is nobody too. Why is this neccessary? Why not set
>> it to root?

> what is better :
> root:root & other= r+x
> or 
> nobody:nobody & other=nothing
> ?
> only httpd(nobody) needs to read this file
> so why don't give it minimal perms ?

> anyway there is a chmod 550 lost 
> (see in lfs/configroot) !

I would prefer, for addon-lang dir:
  root@ipcop147cvs:/var/ipcop # ls -al | grep addon-lang
  drw-r--r--   2 root   root    1024 2005-05-26 16:39 addon-lang
for cache file:
  root@ipcop147cvs:/var/ipcop # ls -al /var/run/ | grep cache
  -r--r--r--   1 root   root 56806 2005-05-26 18:40 cache-lang.pl

Directory is only writable as root. Cache file is only writable as
root too.
 --> Code injection is _not_ possible!


>> > Perhaps the radical solution is to use only the cachefile:
>> > if (cachefile does not exit) die "Rebuild your language
>> > config";  !
>>
>> Not user friendly! Don't do this! A low-brow user will not know what
>> to do :-(
> no

no means, "ok will not do this"??


>> Some other issues:
>> 1) In the code is the comment:
>>      # It's up to add-on writer to select non conflicting name
>>      # and respect standart   %tr = (%tr, 'name' => 'value' );
>>    But what is if an addon lang file does not contain the " = (%tr,",
>>    all previous lang entries are lost?! Here is the biggest issue that
>>    ipcop files/entries are read first. A broken addon lang file erases
>>    all ipcop entries!
>> 2) An addon can overwrite _all_ IPCop lang entries, because the ipcop
>>    lang files are read first.
>> 3) The current code does not read the "en" addon files if there is a
>>    "nativ" addon lang file. But some translated files are not complete
>>    and have not all entries translated. The none translated entries are
>>    not available in the cgi's.
>> 4) The call for a rebuild. How should a (bash) addon install script
>>    call the rebuild function? Maybe i'm stupid and this is easy, but
>>       perl '/var/ipcop/lang.pl &Lang::RebuildCacheLang()'
>>    is not working from commandline.
> 1)2)Developpers are not 'babyes' !

But they are people who can do misstakes. If there is a simple
solution to avoid this issue why not using it??

We know about the issue and don't use the simple solution
 --> _very_ bad code/decision!

> 3) may be true yes. A partial translation of addon. Why not !
> 4) it does ! With correct perl syntax.

And this sytax is??


> 1)2)4) A document on 'how addon integrate into ipcop ' will 
> be done I think. When everybody will be ok !!!
> (langs is only one part)


>> I prefere an extra root script for the generate-cache-file-code. It
>> would be easier for addons to call it on addon install. If the cache
>> files needs to be rebuild from Gui (on lang change for example) it
>> could be done by a suid binary. The suid binary would only do suid
>> stuff and call the root script.
> if anybody is able to lauch 'rebuild' of this file, with suid for example,
> all problematics 'code injection' comes  again.

Not with correct permissions, see above.

> That why only under root it's ok. Of course the program could check
> line by line '.pl' contents before assembling a big one. But is it
> really usefull ? For a one-time lang switch ?

Not necessary, with correct permissions (only root writable) you can
avoid injection. When there is a programm/hacker which can write as
root, there is lost all anyway.

>> A cosmetical issue is the missing line feed and the unsorted order in
>> the cache file. The lang entries are written unsorted in one line,
>> hard to look if an lang entry is availble.
> It's a cache ! To read entries => original source file.

How do you look if your cache-file-build-code works correct and writes
all entries ;-) 

>> ** To issue 2: It is possible that the "native" lang file overwrites
>>    english lang entries, but the following read of "native" ipcop
>>    entries will clean-up this. So it is possible for an addon to
>>    provide lang entries which are not translated in the "native" ipcop
>>    file.
> ??? sorry, don't understand ..... ;-)

Example:
- IPCop language Lithuanian is not complete.
- On cachefile build you read all existing lang keys from en file.
- An addon which provides some additional-translated entries exists.
  This addon .lt file is read next, the additional translated entries
  overwrite the existing en entries.
- At least we read the IPCop .lt file. Maybe some entries are double
  between addon .lt file and IPCop .lt file. The double keys are
  overwritten again by the ipcop .lt file.

So the ipcop lang files have higher importance than the addon lang
files.

Better description?

Achim

Le Jeudi 26 Mai 2005 15:11, Achim Weber a =E9crit :
> [...]
>
> > Hello Achim,
> > Because my last 'Lang.pl' do the same thing now,=3D20
> > with total compatibility, I would prefer I you test it
> > with some other '*.pl' than mines !!!
>
> ok, have build 1.4.7 from CVS and tested/looked at the current code. I
> see some issues with current code.
>
> > With actual permissions, two mode can be used
> > with or whitout cachefile.
> > Only root can create remove it.
>
> No, the owner of "addon-lang" dir is still nobody! This needs to be
> corrected.
>
> root@ipcop147cvs:/var/ipcop # ls -al | grep addon-lang
> drwxr-xr-x   2 nobody nobody  1024 2005-05-26 14:15 addon-lang
>
> > the "addonlang" dir must be only readeable.
> >
> > What needs to be validated is that 'someone'
> > cannot add a lang file and remove the=3D20
> > cachefile (ie injection).
>
> jep, the cache file is nobody too. Why is this neccessary? Why not set
> it to root?

what is better :
root:root & other=3D r+x
or=20
nobody:nobody & other=3Dnothing
?
only httpd(nobody) needs to read this file
so why don't give it minimal perms ?

anyway there is a chmod 550 lost=20
(see in lfs/configroot) !

> > Perhaps the radical solution is to use only the cachefile:
> > if (cachefile does not exit) die "Rebuild your language
> > config";  !
>
> Not user friendly! Don't do this! A low-brow user will not know what
> to do :-(
no=20



> Some other issues:
> 1) In the code is the comment:
>      # It's up to add-on writer to select non conflicting name
>      # and respect standart   %tr =3D (%tr, 'name' =3D> 'value' );
>    But what is if an addon lang file does not contain the " =3D (%tr,",
>    all previous lang entries are lost?! Here is the biggest issue that
>    ipcop files/entries are read first. A broken addon lang file erases
>    all ipcop entries!
> 2) An addon can overwrite _all_ IPCop lang entries, because the ipcop
>    lang files are read first.
> 3) The current code does not read the "en" addon files if there is a
>    "nativ" addon lang file. But some translated files are not complete
>    and have not all entries translated. The none translated entries are
>    not available in the cgi's.
> 4) The call for a rebuild. How should a (bash) addon install script
>    call the rebuild function? Maybe i'm stupid and this is easy, but
>       perl '/var/ipcop/lang.pl &Lang::RebuildCacheLang()'
>    is not working from commandline.
1)2)Developpers are not 'babyes' !
3) may be true yes. A partial translation of addon. Why not !
4) it does ! With correct perl syntax.=20
1)2)4) A document on 'how addon integrate into ipcop ' will=20
be done I think. When everybody will be ok !!!
(langs is only one part)

>
> I have uploaded a new/updated script to the RFE [1] last week. Thought
> you would look into it!? It does not have issues 1-4 **.
ok


> I prefere an extra root script for the generate-cache-file-code. It
> would be easier for addons to call it on addon install. If the cache
> files needs to be rebuild from Gui (on lang change for example) it
> could be done by a suid binary. The suid binary would only do suid
> stuff and call the root script.
if anybody is able to lauch 'rebuild' of this file, with suid for example,
all problematics 'code injection' comes  again.
That why only under root it's ok. Of course the program could check
line by line '.pl' contents before assembling a big one. But is it
really usefull ? For a one-time lang switch ?



> A cosmetical issue is the missing line feed and the unsorted order in
> the cache file. The lang entries are written unsorted in one line,
> hard to look if an lang entry is availble.
It's a cache ! To read entries =3D> original source file.


> If there are questions about [2] feel free to ask. There are some
> different paths in my script, but this are minor changes only.
> Too I can do the suid binary code if needed/desired!
>
> Achim
>
>
> ** To issue 2: It is possible that the "native" lang file overwrites
>    english lang entries, but the following read of "native" ipcop
>    entries will clean-up this. So it is possible for an addon to
>    provide lang entries which are not translated in the "native" ipcop
>    file.
??? sorry, don't understand ..... ;-)



=46ranck

Bugs item #1209193, was opened at 2005-05-26 11:54
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=1209193&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Security (Patches etc)
Group: 1.4.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido Rebert (tartarugavespa)
Assigned to: Nobody/Anonymous (nobody)
Summary: password crashed after update

Initial Comment:
I installed latest update 1.4.6 update and after
applyed, roots password crashed. I cannot log in from
ssh or physically in the computer but web admin with
admin user, works great...
anyone has any idea?? thanks, Guido

Installed updates:   	
	
ID 	Title 	Description 	Released 	Installed
006	1.4.6 update	Upgrade snort, add oinkmaster to
update rules. Patch tcpdump, gzip, vim, ibod. Upgrade
to bind-9.2.5, dnsmasq-2.22, pptp-1.6.0,
wireless-tools.27. Allow easydns and zoneedit to update
without a HOSTNAME. Use english language in setup for
(zh,lt,ro,ru,th). Allow correct default gateway change
with static IP. Remove sitefinder workaround. Allow new
options to dhcp.cgi. Fix some vpnmain.cgi errors. Fix
dyndns ip behind router, erase ipcache file when force
update. Fix wrong firmware speedtouch selection during
upload. Fix start squid if enabled on blue or green.
Fix various typo with vpnmain.cgi, a possible crash of
the interface on a click on erase. Remove in
rc.netaddress.up call to dsnmask and ipsecctrl (fix
SF11752 ??) Stop and clear module help on reboot for
Conexant PCI and usb adsl.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=1209193&group_id=40604

[...]

> Hello Achim,
> Because my last 'Lang.pl' do the same thing now,=20
> with total compatibility, I would prefer I you test it
> with some other '*.pl' than mines !!!

ok, have build 1.4.7 from CVS and tested/looked at the current code. I
see some issues with current code.

> With actual permissions, two mode can be used
> with or whitout cachefile.
> Only root can create remove it.

No, the owner of "addon-lang" dir is still nobody! This needs to be
corrected.

root@ipcop147cvs:/var/ipcop # ls -al | grep addon-lang
drwxr-xr-x   2 nobody nobody  1024 2005-05-26 14:15 addon-lang


> the "addonlang" dir must be only readeable.

> What needs to be validated is that 'someone'
> cannot add a lang file and remove the=20
> cachefile (ie injection).

jep, the cache file is nobody too. Why is this neccessary? Why not set
it to root?

> Perhaps the radical solution is to use only the cachefile:
> if (cachefile does not exit) die "Rebuild your language
> config";  !

Not user friendly! Don't do this! A low-brow user will not know what
to do :-(

Some other issues:
1) In the code is the comment:
     # It's up to add-on writer to select non conflicting name
     # and respect standart   %tr = (%tr, 'name' => 'value' );
   But what is if an addon lang file does not contain the " = (%tr,",
   all previous lang entries are lost?! Here is the biggest issue that
   ipcop files/entries are read first. A broken addon lang file erases
   all ipcop entries!
2) An addon can overwrite _all_ IPCop lang entries, because the ipcop
   lang files are read first.
3) The current code does not read the "en" addon files if there is a
   "nativ" addon lang file. But some translated files are not complete
   and have not all entries translated. The none translated entries are
   not available in the cgi's.
4) The call for a rebuild. How should a (bash) addon install script
   call the rebuild function? Maybe i'm stupid and this is easy, but
      perl '/var/ipcop/lang.pl &Lang::RebuildCacheLang()'
   is not working from commandline.

I have uploaded a new/updated script to the RFE [1] last week. Thought
you would look into it!? It does not have issues 1-4 **.

I prefere an extra root script for the generate-cache-file-code. It
would be easier for addons to call it on addon install. If the cache
files needs to be rebuild from Gui (on lang change for example) it
could be done by a suid binary. The suid binary would only do suid
stuff and call the root script.

A cosmetical issue is the missing line feed and the unsorted order in
the cache file. The lang entries are written unsorted in one line,
hard to look if an lang entry is availble.

If there are questions about [2] feel free to ask. There are some
different paths in my script, but this are minor changes only.
Too I can do the suid binary code if needed/desired!

Achim


** To issue 2: It is possible that the "native" lang file overwrites
   english lang entries, but the following read of "native" ipcop
   entries will clean-up this. So it is possible for an addon to
   provide lang entries which are not translated in the "native" ipcop
   file.

[1] http://sourceforge.net/tracker/index.php?func=detail&aid=1200452&group_id=40604&atid=428519
[2] Script "gen_CacheLangFile.pl" in RFE [1]

Hi

I have been researching Bridging firewall IPS  and wonder if it is going 
to be included in IPCop or would it be better suited as a sub-project?

Christiaan