Re: nssov change proposal

[Kean Johnston <kean.johnston@gmail.com>]

> The most basic example for your case is
>   access to dn.exact=cn=host1,ou=hosts,... attrs=authorizedService
>     by group.exact=cn=dbas,ou=access,... compare
That is exactly what I currently have. The problem is this. There are 
multiple hostAccessGroup's possible for each host. Its a list, not a single 
group. The example you give works only for a single group. I guess it would 
be possible to list the access groups in the ACL's rather than using an 
attribute of the host, but that doesn't seem scalable to me. It also has 
implications of security, as to change a host's access an administrator 
will need permission to change ACL's which is considerably more "powerful" 
operation than giving a sysadmin teh ability to add or remove 
hostAccessGroup (or whatever attribute) from a host entry. It is also 
moving the data away from where its relevant. The ou=hosts entries are 
supposed to describe hosts. But this:

access to dn.exact=cn=host1,ou=hosts... attrs=authorizedService
  by group.exact=cn=dbas,ou=access... compare
  by group.exact=cn=admins,ou=access.. compare

access to dn.exact=cn-host2.....

access to dn.exact=host3....

etc etc ... seems to be less optimal than:

dn: cn=host1,...
hostAccessGroup: dbas
hostAccessGroup: admins

dn: cn=host2...
... etc etc.

It also has implications for management tools. In the one case (yours), 
information about the host is split between the ou=hosts and the ACLs. In 
the other, all information about the host is in the ou=hosts entry. In a 
large organisation, I can see considerable problems if a basic sysadmin 
requires rights to change ACL's (think: can grant himself access to HR 
attributes) versus just being able to grant or deny access to ssh for a 
given host.

Thoughts?

Kean