Re: [RFC] SECMARK 1.1

[Patrick McHardy <kaber@trash.net>]

James Morris wrote:
> On Sun, 14 May 2006, Patrick McHardy wrote:
> 
> 
>>James Morris wrote:
>>
>>>@@ -135,6 +175,9 @@ static int __init xt_secmark_init(void)
>>> {
>>> 	int err;
>>> 
>>>+	if (tracking_enabled())
>>>+		need_conntrack();
>>>+
>>
>>This will load the conntrack modules even if the track flag is not set.
> 
> 
> I guess need_conntrack() could be moved to checkentry() and only called 
> if the track flag is set.


That won't help, the function itself does nothing, its just a symbol
dependency.

>>Wouldn't it be better to put everything related to connection marking
>>in the CONNSECMARK target?
> 
> 
> It's more efficient this way, and simpler to manage.  
> 
> Currently, after security marking, the chain should normally terminate 
> with a -j ACCEPT.  Requiring the use of CONNSECMARK to label connections 
> means inserting another rule before terminating the chain.
> 
> Also, security marking for connections only occurs in the context of 
> copying the security mark from packets, so there's no reason to build a 
> general feature to do this into CONNSECMARK.
> 
> Another possibility would be to get rid of CONNSECMARK completely and have 
> SECMARK copy security marks from connections to packets via the use of a 
> different flag (perhaps change --track into --save-state and then have 
> --restore-state, or similar).


The reason why I'm asking is because my understanding is that SECMARK
would also be useful without conntrack, but automatically pulling in
the module leaves no option not to use conntrack except not to compile
this part in.