Drop the second "owner" argument from invirt.authz.expandAdmin.

If we find out later that some authz mechanism requires knowing the
owner to interpret the administrator, we can add it back. But so long
as all authz modules live in our tree, let's not add unnecessary API
complexity just because we can.

svn path=/trunk/packages/xvm-authz-locker/; revision=2988

diff --git a/python/invirt/authz.py b/python/invirt/authz.py
index cbfc28a..59b480e 100644 (file)
--- a/python/invirt/authz.py
+++ b/python/invirt/authz.py
@@ -48,15 +48,12 @@ def expandOwner(name):
             raise
 
 
             raise
 
 

-def expandAdmin(name, owner):
+def expandAdmin(name):

     """Expand an administrator to a list of authorized users.
 
     """Expand an administrator to a list of authorized users.
 

-    Because the interpretation of an administrator might depend on the
-    owner, the owner is passed in as an argument.
-
-    However, in the case of locker-based authentication, the
-    administrator is always interpreted as an AFS entry (either a user
-    or a group) in the home cell (athena.mit.edu for XVM).
+    For locker-based authorization, the administrator is always
+    interpreted as an AFS entry (either a user or a group) in the
+    machine's home cell (athena.mit.edu for XVM).

     """
     cell = config.authz.afs.cells[0].cell
     auth = _authenticate(cell)
     """
     cell = config.authz.afs.cells[0].cell
     auth = _authenticate(cell)