[tac_plus] Re: tac_plus enhancement
john heasley
heas at shrubbery.net
Tue Aug 14 00:09:03 UTC 2007
Mon, Aug 13, 2007 at 08:59:00AM +0200, Kiss Gabor (Bitman):
> > > I think it would be useful if a user or group could be member
> > > of multiple groups.
>
> > How do you propose conflicts of attributes between groups be resolved?
>
> This problem is like in object oriented languages: if more than
> one parent class provides the same method which one is to be executed?
> I made an arbitrary decision. I like PERL so I follow the PERL model:
> I do a recursive, depth-first, left-to-right search till I found
> the requested attribute.
> However the primary goal of this enhancement is to allow fine grained
> but simple configuration.
> In the tipical case there are no conflicting attributes.
> Properties should be organized into orthogonal groups, i.e. NAS location
> and allowed commands:
>
> acl = core_routers {
> permit = ...
> }
>
> acl = local_switches {
> permit = ...
> }
>
> group = red {
> acl = core_routers
> }
>
> group = green {
> acl = local_switches
> }
>
> group = show_ip {
> cmd = show {
> permit ^ip
> }
> }
> group = telnet_private {
> cmd = telnet {
> permit ^192\.168\.
> }
> }
Any of these are good examples of what I mean. Take user chico. if chico:
a) hits the implicit deny of local_switches, does it deny or go on to
telnet_private?
b) if local_switches would explicitly accept/deny it, should it check
telnet_private.
> user = chico {
> member green
> member telnet_private
> }
>
> user = harpo {
> member green
> member show_ip
> }
>
> user zeppo {
> member red
> member telnet_private
> }
>
> Gabor
More information about the tac_plus
mailing list