netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* nfqueue: Get pid of socket owner
@ 2016-11-07 14:21 David Buchmann
  2016-11-07 16:38 ` Florian Westphal
  0 siblings, 1 reply; 3+ messages in thread
From: David Buchmann @ 2016-11-07 14:21 UTC (permalink / raw)
  To: netfilter-devel

Hi,

I've started work to add support in the nfnetlink_queue kernel module for
sending the pid of the process owning the socket triggering nfqueue, and I
want to add the userspace support in libnetfilter_queue, but before I get
too invested in that work I just want to check whether there are any
objections to such a feature in either the kernel or in the
libnetfilter_queue library?

https://github.com/wuurrd/linux/commit/79d12e93ca2a28c0939937a5a690943311e4bf6c

David

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: nfqueue: Get pid of socket owner
  2016-11-07 14:21 nfqueue: Get pid of socket owner David Buchmann
@ 2016-11-07 16:38 ` Florian Westphal
  2016-11-07 17:09   ` Florian Westphal
  0 siblings, 1 reply; 3+ messages in thread
From: Florian Westphal @ 2016-11-07 16:38 UTC (permalink / raw)
  To: David Buchmann; +Cc: netfilter-devel

David Buchmann <david@jazznetworks.com> wrote:
> I've started work to add support in the nfnetlink_queue kernel module for
> sending the pid of the process owning the socket triggering nfqueue, and I
> want to add the userspace support in libnetfilter_queue, but before I get
> too invested in that work I just want to check whether there are any
> objections to such a feature in either the kernel or in the
> libnetfilter_queue library?
> 
> https://github.com/wuurrd/linux/commit/79d12e93ca2a28c0939937a5a690943311e4bf6c

I think this should just be added to nfqnl_put_sk_uidgid(), and just use
the new sk->sk_uid that got added to net-next recently:

--- a/net/netfilter/nfnetlink_queue.c
+++ b/net/netfilter/nfnetlink_queue.c
@@ -271,6 +271,10 @@ static int nfqnl_put_sk_uidgid(struct sk_buff *skb, struct sock *sk)
                        goto nla_put_failure;
        }
        read_unlock_bh(&sk->sk_callback_lock);
+
+       if (nla_put_be32(skb, NFQA_PID, htonl(sk->sk_uid)))
+               return -1;
+
        return 0;
 

As we don't need any locking for this I'd also be fine to just always
pass this to userspace regardless of any feature flags.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: nfqueue: Get pid of socket owner
  2016-11-07 16:38 ` Florian Westphal
@ 2016-11-07 17:09   ` Florian Westphal
  0 siblings, 0 replies; 3+ messages in thread
From: Florian Westphal @ 2016-11-07 17:09 UTC (permalink / raw)
  To: Florian Westphal; +Cc: David Buchmann, netfilter-devel

Florian Westphal <fw@strlen.de> wrote:
> David Buchmann <david@jazznetworks.com> wrote:
> > I've started work to add support in the nfnetlink_queue kernel module for
> > sending the pid of the process owning the socket triggering nfqueue, and I
> > want to add the userspace support in libnetfilter_queue, but before I get
> > too invested in that work I just want to check whether there are any
> > objections to such a feature in either the kernel or in the
> > libnetfilter_queue library?
> > 
> > https://github.com/wuurrd/linux/commit/79d12e93ca2a28c0939937a5a690943311e4bf6c
> 
> I think this should just be added to nfqnl_put_sk_uidgid(), and just use
> the new sk->sk_uid that got added to net-next recently:

Grrr, too late, sorry :/

I think you should add this to nfqnl_put_sk_uidgid though, no need to
grab the locks twice.

We'd also have to add appropriate warnings that this pid isn't reliable.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2016-11-07 17:11 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-11-07 14:21 nfqueue: Get pid of socket owner David Buchmann
2016-11-07 16:38 ` Florian Westphal
2016-11-07 17:09   ` Florian Westphal

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).