[tac_plus] Re: Different privs for different devices?

[john heasley]

Wed, Jun 30, 2010 at 11:45:53PM +0200, Alan McKinnon:
> On Wednesday 30 June 2010 23:27:12 Paul Floyd wrote:
> > Hi all -
> > 
> > New to the list and tac_plus.  I'm trying to figure out if there's a way to
> > grant a set of users one privilege level on one set of devices and a
> > different privilege level on another set of devices.  My best guess at a
> > config to do this was something like this:
> > 
> > =====
> > 
> > group = helpdesk_full {
> >     acl = routers_full_access
> >     service = exec {
> >     priv-lvl = 15
> >     }
> > }
> > 
> > group = helpdesk_limited {
> >     acl = routers_limited_access
> >     service = exec {
> >     priv-lvl = 7
> >     }
> >     member = helpdesk_full
> > }
> > 
> > group = helpdesk {
> >     login = file /etc/tacacs/users
> >     member = helpdesk_limited
> > }
> > 
> > ====
> > 
> > However when I tried this, it seemed a member of the helpdesk group was
> > able to log in to a router in the "routers_limited access" ACL, but not
> > one in the "routers_full_access" group.  If I'm interpreting the debug
> > correctly, it appears tac_plus processes the router_limited_access ACL and
> > immediately returns a login rejected message.  It never tries to match
> > against the
> > routers_full_access ACL.
> > 
> > Is what I'm trying to accomplish possible with tac_plus, and if so, how do
> > I go about it?
> 
> tac-plus's ability to assign rights to users is deliberately simplistic. A 
> user belongs to one group, which belong to one group, etc, etc till you reach 
> a group that is not a member of another group.
> 
> Rules are applied on a "first match wins" basis. The user in group "helpdesk" 
> has no acl or rights, so tac_plus checks the group config. That does have an 
> acl and rights so they are applied and used. End of story.
> 
> It is a common error to assume that tac_plus walks the entire group 
> inheritance tree and does some complex resolution to find the rights to apply. 
> It does no such thing - it looks in a strict order and uses the first rule it 
> finds.
> 
> The reason for this is simple - conflict resolution. John mentioned as much 
> about 6 months ago and it's a horrible problem to solve (I'm dealing with the 
> same thing myself and reaching the same conclusion). How do you resolve 
> opposing conflicts in rights? John's approach is to avoid the entire problem 
> and guarantee it can't happen.

I think that you make some more complex decisions by using external
authorization scripts.

> A sensible approach that cause you more work than you think proper but leave 
> you sane is to maintain two seperate group, acl and rights definitions, even 
> if they overlap to greater or lesser degree.
> 
> Or, Gabor might drop by with a suggestion, he has some very useful patches in 
> his collection but I haven't tried them enough to comment.

indeed he does.  I hope to import them (possibly w/ some adjustment - sorry)
once i get a better config parser completed.