Argus memory issues

[Carter Bullard]

Hey Russell,
My fault and sorry to mislead.  This is the job of radium, but there is
no support for this in radium() today, because I couldn't figure out a
reasonable way to configure it for this function!!!   So this is  
something
we want to put into radium(), just need some dialog as to what is the
best way to do it.

The removal of data is currently being done by rastrip(), and this  
type of
setup works (or should work) today:

    rastrip -S dataSource -M -suser -M -duser -w - | radium -P 12345

clients would have access to your flow sans user data from port 12345.

Embedding a rastrip() function into radium is a no brainer, the
question is how do you want to configure radium to know who
should get what content?  This is a good feature, but I haven't had
much time to think about the configuration issues, and this is a
great research topic, as we're really talking about semantic access
control, which is pretty cool!!!

So, what should we base the access control on?  Without using our
SASL support for strong authentication, we've really only got source
address as an identifier for control.    With our sasl implementation
we can have user oriented data access control.

And we can support two types of control, server enforced, which is
our strategy for security now (the argus or radium enforces its local
policy on level of protection for data and the client conforms or  
loses),
and user filter based, where we have the client tell argus or radium
what data its interested in.

I like all of these strategies, and would definitely like to work on  
them
after the argus-3.0 release.

So what do you think?

Oh yes, I still have a small memory argus and a new client coming
that is needed to be compatible, so don't worry if the radium() above
has an issue with the small memory argus, just temporary insanity.

Carter

On Aug 25, 2007, at 12:23 AM, Russell Fulton wrote:


>
>
> Carter Bullard wrote:
>
>> Hey Russell,
>> I'd have one argus, and two clients reading the two.  Its much more
>> expensive
>> to have multiple argi, than multiple clients.  If you want to have  
>> one
>> client get
>> user data and the other not, that is ideally the job of radium(),  
>> just
>> need to
>> figure out how to configure it.
>>
>>
> So I'm looking at radium -- straight forward, except that I can't see
> how to specify that one file gets user data and the other does  
> not.  All
> I can see to configure is a "filter", so far as I know only the -s  
> flag
> allows you to manipulate the data fields???
>
> I knew I should have been using radium for ages -- it will simply
> several things I do.  But I'm in that dam bind that I don't have  
> enough
> time to do the work that I know will save me heaps in the long term.
> Sigh...
>
> Russell
>
>
>