[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