[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1344549920.31104.701.camel@edumazet-glaptop>
Date: Fri, 10 Aug 2012 00:05:20 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: Casey Schaufler <casey@...aufler-ca.com>
Cc: Eric Paris <eparis@...isplace.org>,
Paul Moore <paul@...l-moore.com>,
David Miller <davem@...emloft.net>,
John Stultz <johnstul@...ibm.com>,
"Serge E. Hallyn" <serge@...lyn.com>,
lkml <linux-kernel@...r.kernel.org>,
James Morris <james.l.morris@...cle.com>,
selinux@...ho.nsa.gov, john.johansen@...onical.com,
LSM <linux-security-module@...r.kernel.org>,
netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH] ipv4: tcp: security_sk_alloc() needed for unicast_sock
On Thu, 2012-08-09 at 14:53 -0700, Casey Schaufler wrote:
> On 8/9/2012 2:29 PM, Eric Dumazet wrote:
> > smack_sk_alloc_security() uses smk_of_current() : What can be the
> > meaning of smk_of_current() in the context of 'kernel' sockets...
>
> Yes, and all of it's callers - to date - have had an appropriate
> value of current. It is using the API in the way it is supposed to.
> It is assuming a properly formed socket. You want to give it a
> cobbled together partial socket structure without task context.
> Your predecessor did not have this problem.
My predecessor ? You mean before the patch ?
tcp socket was preallocated by at kernel boot time.
What is the 'user' owning this socket ?
You guys focus on an implementation detail of TCP stack.
You should never use this fake socket.
I repeat : There are no true socket for these control packets.
If you want them, then you'll have to add fields in timewait socket.
I can decide to rewrite the whole thing just building a TCP packet on
its own, and send it without any fake socket.
Some guy 15 years ago tried to reuse some high level functions, able to
build super packets and use sophisticated tricks, while we only want so
send a 40 or 60 bytes packet.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists