decided to put this into a separate module. based on ipt_owner.c.
does full program's pathname. like ipt_owner, only suitable for
outgoing connections.
userspace-netfilter-patch sent to bugs.debian.org (270852).
as was kindly pointed out already, dealing with per-program
per-packet filtering is at least O(N*M) and some cacheing
would help.
... but it's better than O(N*M*L) in userspace (in fireflier's
present ip_queueing userspace code).
issue of where new function proc_task_dentry_lookup() should
go is still outstanding and i don't have the knowledge or authority
to say or even advise most appropriate location.
l.
--
--
Truth, honesty and respect are rare commodities that all spring from
the same well: Love. If you love yourself and everyone and everything
around you, funnily and coincidentally enough, life gets a lot better.
--
<a href="http://lkcl.net"> lkcl.net </a> <br />
<a href="mailto:[email protected]"> [email protected] </a> <br />
Luke Kenneth Casson Leighton wrote:
> decided to put this into a separate module. based on ipt_owner.c.
> does full program's pathname. like ipt_owner, only suitable for
> outgoing connections.
I agree that it would be useful to match the full path, but
the patch is broken, as are the owner match's pid-, sid- and
command-matching options. You can't grab files->file_lock
outside of process context. Besides, we want to consolidate
functionality, not add new matches that do basically the same
as existing ones.
Regards
Patrick
On Sat, Sep 11, 2004 at 02:51:24PM +0200, Patrick McHardy wrote:
> Luke Kenneth Casson Leighton wrote:
> >decided to put this into a separate module. based on ipt_owner.c.
> >does full program's pathname. like ipt_owner, only suitable for
> >outgoing connections.
>
> I agree that it would be useful to match the full path, but
> the patch is broken, as are the owner match's pid-, sid- and
> command-matching options. You can't grab files->file_lock
> outside of process context.
what should be done instead?
what code is there around that i can copy that does a proper job?
l.
On Sat, Sep 11, 2004 at 02:29:35PM +0100, Luke Kenneth Casson Leighton wrote:
> On Sat, Sep 11, 2004 at 02:51:24PM +0200, Patrick McHardy wrote:
> > Luke Kenneth Casson Leighton wrote:
> > >decided to put this into a separate module. based on ipt_owner.c.
> > >does full program's pathname. like ipt_owner, only suitable for
> > >outgoing connections.
> >
> > I agree that it would be useful to match the full path, but
> > the patch is broken, as are the owner match's pid-, sid- and
> > command-matching options. You can't grab files->file_lock
> > outside of process context.
thing is, you see, i know just enough to be dangerous.
using files->file_lock a) seems to work b) is accepted code in the
kernel.
if someone else has the experience and knowledge to fix ipt_owner.c
i'll quite happily cut/paste that instead - once it's fixed.
in the meantime...
Luke Kenneth Casson Leighton wrote:
> On Sat, Sep 11, 2004 at 02:29:35PM +0100, Luke Kenneth Casson Leighton wrote:
>
> thing is, you see, i know just enough to be dangerous.
>
> using files->file_lock a) seems to work b) is accepted code in the
> kernel.
It seems to work - on UP where it is a NOP. On SMP it will deadlock.
That we have some broken code doesn't mean we want more of it :)
> if someone else has the experience and knowledge to fix ipt_owner.c
> i'll quite happily cut/paste that instead - once it's fixed.
The "fix" is quite easy, replace all occurences of
spin_lock(&files->file_lock) in the kernel by spin_lock_bh.
But that's not going to be accepted. IIRC the SELinux guys
want to label packets with the name of the sending process,
maybe we can use this for the owner match once it's done.
Regards
Patrick
On Sat, 2004-09-11 at 14:51 +0200, Patrick McHardy wrote:
> Luke Kenneth Casson Leighton wrote:
> > decided to put this into a separate module. based on ipt_owner.c.
> > does full program's pathname. like ipt_owner, only suitable for
> > outgoing connections.
>
> I agree that it would be useful to match the full path, but
> the patch is broken, as are the owner match's pid-, sid- and
> command-matching options. You can't grab files->file_lock
> outside of process context. Besides, we want to consolidate
> functionality, not add new matches that do basically the same
> as existing ones.
This is a binary compatibility issue, I don't think it's possible to add
Lukes functionality to ipt_owner without breaking iptables
compatibility.
--
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source http://www.scaramanga.co.uk/scaramanga.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D
On Sat, Sep 11, 2004 at 03:49:35PM +0100, Gianni Tedesco wrote:
> On Sat, 2004-09-11 at 14:51 +0200, Patrick McHardy wrote:
> > Luke Kenneth Casson Leighton wrote:
> > > decided to put this into a separate module. based on ipt_owner.c.
> > > does full program's pathname. like ipt_owner, only suitable for
> > > outgoing connections.
> >
> > I agree that it would be useful to match the full path, but
> > the patch is broken, as are the owner match's pid-, sid- and
> > command-matching options. You can't grab files->file_lock
> > outside of process context. Besides, we want to consolidate
> > functionality, not add new matches that do basically the same
> > as existing ones.
>
> This is a binary compatibility issue, I don't think it's possible to add
> Lukes functionality to ipt_owner without breaking iptables
> compatibility.
weeeelllll... there's nothing to stop you adding a header file
ipt_owner_program.h instead :)
i know it breaks the convention but hey.
l.
--
--
Truth, honesty and respect are rare commodities that all spring from
the same well: Love. If you love yourself and everyone and everything
around you, funnily and coincidentally enough, life gets a lot better.
--
<a href="http://lkcl.net"> lkcl.net </a> <br />
<a href="mailto:[email protected]"> [email protected] </a> <br />
On Sat, Sep 11, 2004 at 04:36:14PM +0200, Patrick McHardy wrote:
> Luke Kenneth Casson Leighton wrote:
> >On Sat, Sep 11, 2004 at 02:29:35PM +0100, Luke Kenneth Casson Leighton
> >wrote:
> >
> > thing is, you see, i know just enough to be dangerous.
> >
> > using files->file_lock a) seems to work b) is accepted code in the
> > kernel.
>
> It seems to work - on UP where it is a NOP. On SMP it will deadlock.
> That we have some broken code doesn't mean we want more of it :)
*cackle*
> > if someone else has the experience and knowledge to fix ipt_owner.c
> > i'll quite happily cut/paste that instead - once it's fixed.
>
> The "fix" is quite easy, replace all occurences of
> spin_lock(&files->file_lock) in the kernel by spin_lock_bh.
> But that's not going to be accepted.
's'just'a'big'job'for "replace", innit?
[btw _what_ is the "replace" command doing in the debian mysql package??]
> IIRC the SELinux guys
> want to label packets with the name of the sending process,
> maybe we can use this for the owner match once it's done.
... well, given that i'll be rolling this out (broken or not)
on a single-processor SELinux system, whatever is added
[for selinux] would also need to be useable by thingy.
ipt_owner.c. as well.
l.
--
--
Truth, honesty and respect are rare commodities that all spring from
the same well: Love. If you love yourself and everyone and everything
around you, funnily and coincidentally enough, life gets a lot better.
--
<a href="http://lkcl.net"> lkcl.net </a> <br />
<a href="mailto:[email protected]"> [email protected] </a> <br />