LOG target - log GID

Hi,

While I was browsing through the files in my home directory
I stumbled 
upon my patch from
May 2003 that adds to the LOG target an option to log UID
and GID.

I noticed that someone already has done that in the past 4
years 
However currently LOG only logs UID. My patch used to log
GID too, so
what do you say about applying the patches attached.

log_gid_kern.diff - patch ipt_LOG.c and ip6t_LOG.c
log_gid_user.diff - patch libipt_LOG.c and libip6t_LOG.c

Please CC me, I am not on the list for some time now.
Best Regards,
Maciej Soltysiak

diff -Nru linux-2.6.22.orig/net/ipv4/netfilter/ipt_LOG.c 
linux-2.6.22/net/ipv4/netfilter/ipt_LOG.c
--- linux-2.6.22.orig/net/ipv4/netfilter/ipt_LOG.c   
2007-07-10 
20:57:44.000000000 +0200
+++ linux-2.6.22/net/ipv4/netfilter/ipt_LOG.c    2007-07-10

21:01:16.000000000 +0200
 -337,7
+337,9 
     if ((logflags & IPT_LOG_UID) && !iphoff
&& skb->sk) {
        
read_lock_bh(&skb->sk->sk_callback_lock);
         if (skb->sk->sk_socket &&
skb->sk->sk_socket->file)
-            printk("UID=%u ",
skb->sk->sk_socket->file->f_uid);
+            printk("UID=%u GID=%u",
+               
skb->sk->sk_socket->file->f_uid,
+               
skb->sk->sk_socket->file->f_gid);
        
read_unlock_bh(&skb->sk->sk_callback_lock);
     }
 
diff -Nru linux-2.6.22.orig/net/ipv6/netfilter/ip6t_LOG.c 
linux-2.6.22/net/ipv6/netfilter/ip6t_LOG.c
--- linux-2.6.22.orig/net/ipv6/netfilter/ip6t_LOG.c   
2007-07-10 
20:57:44.000000000 +0200
+++ linux-2.6.22/net/ipv6/netfilter/ip6t_LOG.c    2007-07-10

21:01:41.000000000 +0200
 -359,7
+359,9 
     if ((logflags & IP6T_LOG_UID) && recurse
&& skb->sk) {
        
read_lock_bh(&skb->sk->sk_callback_lock);
         if (skb->sk->sk_socket &&
skb->sk->sk_socket->file)
-            printk("UID=%u ",
skb->sk->sk_socket->file->f_uid);
+            printk("UID=%u GID=%u",
+               
skb->sk->sk_socket->file->f_uid,
+               
skb->sk->sk_socket->file->f_gid);
        
read_unlock_bh(&skb->sk->sk_callback_lock);
     }
 }

diff -Nru
iptables-1.3.8-20070709.orig/extensions/libip6t_LOG.c 
iptables-1.3.8-20070709/extensions/libip6t_LOG.c
--- iptables-1.3.8-20070709.orig/extensions/libip6t_LOG.c   
2006-10-10 
08:18:40.000000000 +0200
+++ iptables-1.3.8-20070709/extensions/libip6t_LOG.c   
2007-07-10 
20:52:50.000000000 +0200
 -28,7
+28,7 
 " --log-tcp-sequence        Log TCP sequence
numbers.nn"
 " --log-tcp-options        Log TCP options.nn"
 " --log-ip-options        Log IP options.nn"
-" --log-uid            Log UID owning the local
socket.nn",
+" --log-uid            Log UID/GID owning the local
socket.nn",
 IPTABLES_VERSION);
 }
 
diff -Nru
iptables-1.3.8-20070709.orig/extensions/libipt_LOG.c 
iptables-1.3.8-20070709/extensions/libipt_LOG.c
--- iptables-1.3.8-20070709.orig/extensions/libipt_LOG.c   
2006-10-10 
08:18:40.000000000 +0200
+++ iptables-1.3.8-20070709/extensions/libipt_LOG.c   
2007-07-10 
20:52:46.000000000 +0200
 -28,7
+28,7 
 " --log-tcp-sequence        Log TCP sequence
numbers.nn"
 " --log-tcp-options        Log TCP options.nn"
 " --log-ip-options        Log IP options.nn"
-" --log-uid            Log UID owning the local
socket.nn",
+" --log-uid            Log UID/GID owning the local
socket.nn",
 IPTABLES_VERSION);
 }
 

On Jul 10 2007 21:25, Maciej Sołtysiak wrote:
>
> I noticed that someone already has done that in the
past 4 years 
> However currently LOG only logs UID. My patch used to
log GID too, so
> what do you say about applying the patches attached.

So.. what happens when you ping or a kernel thread (e.g.
knfsd) sends out data,
which do not normally have an owner?


	Jan
-- 

Hi,

From: Maciej So³tysiak <maciej.soltysiakae.poznan.pl>
Date: Tue, 10 Jul 2007 21:25:11 +0200

> Hi,
> 
> While I was browsing through the files in my home
directory I stumbled 
> upon my patch from
> May 2003 that adds to the LOG target an option to log
UID and GID.
> 
> I noticed that someone already has done that in the
past 4 years 
> However currently LOG only logs UID. My patch used to
log GID too, so
> what do you say about applying the patches attached.

We cannot change format of LOG target because that breaks
programs parsing logs.
But it might be possible by introducing new option like
'--log-gid'.

-- Yasuyuki Kozakai

On Jul 12 2007 18:03, Yasuyuki KOZAKAI wrote:
>> Hi,
>> 
>> While I was browsing through the files in my home
directory I stumbled 
>> upon my patch from
>> May 2003 that adds to the LOG target an option to
log UID and GID.
>> 
>> I noticed that someone already has done that in the
past 4 years 
>> However currently LOG only logs UID. My patch used
to log GID too, so
>> what do you say about applying the patches
attached.
>
>We cannot change format of LOG target because that
breaks programs parsing logs.

Hm, then it's time to write a specification on how to
correctly parse things
(namely, splitting at whitespace and parsing the ^S+=
component of it rather
than assuming things were in a fixed order)

>But it might be possible by introducing new option like
'--log-gid'.


	Jan
-- 

From: Jan Engelhardt <jengelhcomputergmbh.de>
Date: Fri, 13 Jul 2007 11:59:21 +0200 (CEST)

> On Jul 12 2007 18:03, Yasuyuki KOZAKAI wrote:
> >> Hi,
> >> 
> >> While I was browsing through the files in my
home directory I stumbled 
> >> upon my patch from
> >> May 2003 that adds to the LOG target an option
to log UID and GID.
> >> 
> >> I noticed that someone already has done that
in the past 4 years 
> >> However currently LOG only logs UID. My patch
used to log GID too, so
> >> what do you say about applying the patches
attached.
> >
> >We cannot change format of LOG target because that
breaks programs parsing logs.
> 
> Hm, then it's time to write a specification on how to
correctly parse things
> (namely, splitting at whitespace and parsing the ^S+=
component of it rather
> than assuming things were in a fixed order)

Unfortunately, there is no way for us to know every program
to do that. So
what we can do is to keep current format including the
number of objects
and white spaces, order of things, and so on.

> >But it might be possible by introducing new option
like '--log-gid'.


-- Yasuyuki Kozakai