From: Evan Broder <broder@mit.edu>
Date: Fri, 5 Feb 2010 16:20:53 +0000 (-0500)
Subject: Drop the second "owner" argument from invirt.authz.expandAdmin.
X-Git-Tag: bdaf8d72f6eb4fda0ef47e9229dd033deb4a63fa~1
X-Git-Url: http://xvm.mit.edu/gitweb/invirt/packages/xvm-authz-locker.git/commitdiff_plain/7824b2db8f1795ea784d70def02c362d48ab91b5?hp=f0ececfc657b2334ed8d1e12a7e235a088e93aef

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
--- a/python/invirt/authz.py
+++ b/python/invirt/authz.py
@@ -48,15 +48,12 @@ def expandOwner(name):
             raise
 
 
-def expandAdmin(name, owner):
+def expandAdmin(name):
     """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)