All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Török Edwin" <edwin@gurde.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: netfilter-devel@lists.netfilter.org,
	fireflier-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org, martinmaurer@gmx.at
Subject: Re: [PATCH 2.6.15.4 1/1][RFC] ipt_owner: inode match supporting both incoming and outgoing packets
Date: Sat, 18 Feb 2006 14:47:31 +0200	[thread overview]
Message-ID: <200602181447.31592.edwin@gurde.com> (raw)
In-Reply-To: <20060218123720.GA1811@infradead.org>

On Saturday 18 February 2006 14:37, Christoph Hellwig wrote:
> On Sat, Feb 18, 2006 at 02:32:14PM +0200, T?r?k Edwin wrote:
> > Is there an alternative for locking the tasklist, and iterating through
> > all the threads to: find out the struct task*  given a struct
> > fown_struct*. Or is there any other way to find out the inode, and
> > mountpoint of that process?
>
> no, and a driver shouldn't do that. 
Ok, can a kernel function that is not part of a driver do that? Something 
like: get_task_from_fown(..), or get_inode_of_process_fown(..)?
> This might sound harsh, but I'd say 
> what you're trying to do is fundamentally doomed ;-)
Since Luke's patch didn't got accepted, I wasn't expecting mine to be.
But I am not giving up this easily. There has to be a way to solve this 
problem. As a last resort, I'll try to maintain this as separate patch to be 
applied to the kernel, but that is something I'd really try to avoid, 
because:
- it would need updating with every kernel version => each kernel version a 
new patch
- fixing bugs would take N times longer (N=kernel version - initial kernel 
version)
- I am no kernel hacker, so I am not the appropiate person to maintain such a 
patch
....

Even if all of it can't be done inside the kernel, I'd like to do as much as I 
can of it, and maybe leave the rest to userspace. (By exporting needed stuff 
via /proc, or /sys, such as socket/inode mappings, socket/process mappings). 
But I believe the proper place to do this is inside the kernel.

Patrick McHardy ([1]) said that SELinux should do this, and it will be ready 
soon. How would SELinux accomplish this?

[1] https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=449

  reply	other threads:[~2006-02-18 12:47 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-18 12:10 [PATCH 2.6.15.4 1/1][RFC] ipt_owner: inode match supporting both incoming and outgoing packets Török Edwin
2006-02-18 12:25 ` Christoph Hellwig
2006-02-18 12:32   ` Török Edwin
2006-02-18 12:37     ` Christoph Hellwig
2006-02-18 12:47       ` Török Edwin [this message]
2006-02-18 13:10         ` Arjan van de Ven
2006-02-18 14:15           ` Török Edwin
2006-02-20 16:26 ` James Morris
2006-02-20 16:42   ` Patrick McHardy
2006-02-20 16:42     ` Patrick McHardy
2006-02-20 17:40   ` Török Edwin
2006-02-20 20:06     ` James Morris
  -- strict thread matches above, loose matches on Subject: below --
2006-02-18 12:20 Török Edwin
2006-02-18 19:28 ` Patrick McHardy
2006-02-18 20:03   ` Török Edwin
2006-02-18 20:07     ` Patrick McHardy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200602181447.31592.edwin@gurde.com \
    --to=edwin@gurde.com \
    --cc=fireflier-devel@lists.sourceforge.net \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martinmaurer@gmx.at \
    --cc=netfilter-devel@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.