[tac_plus] Re: Redesign? (Was: Different privs for different devices?)

[Alan McKinnon]

On Tuesday 06 July 2010 17:30:56 Paul Floyd wrote:
> > I think there is no way to  painlessly(*) add further tests and their
> > 
> > arbitrary combination to the  current syntax.
> > I mean: host originating telnet session, NAS tty, actual  weekday and
> > daytime, number of already live sessions of the user  etc.
> > 
> > Authorization clauses are also uneasy.
> > 
> > *Including backward  compatibility.
> 
> OK, but WHY?  Maybe I'm an idiot, but I'm not seeing how the config syntax
> makes this particularly difficult.  Is this something I just need to read
> the code to understand?

Inasmuch as it affects my setup, the major problem is that to perform
multiple group membership there is something you MUST be able to do in
the config, which tac_plus.conf does NOT do:

conflict resolution

It isn't 1991 anymore and things have moved on. It is trivially easy
to come up with a multiple-group config that both allows and disallows
an action. Or a config that tries to set two defaults in two different
places.

Which one wins?

The stupid (and hopelessly wrong) approach is "first one wins" much
like iptables on Linux. This instantly gets complicated - define
first. Is it the order in which groups are defined? Or the order they
are assigned in the user/group clause? What if you have a hierarchy of
groups with a permit in the top level group, and ambiguous permit *
somewhere in the middle and an explicit deny for the user? There's
only one way to resolve that - John must flip a coin and hard code it
in the source. Which will satisfy exactly 50% of the users......

We're talking AAA here, anything less than a provably correct
algorithm that resolves all conflicts just won't cut it.

You will notice that nothing in the tac_plus config syntax permits any
such resolution, or even an assignment of priority to a rule. And that
any attempt to do so will probably break existing installations.

So even though Gabor is proposing the long way round, I agree with his
ideas in principle. I would give my eyeteeth to disconnect the rule
database from the bulk of the code.

-- 
alan dot mckinnon at gmail dot com