Your post was cut off, but you seem on the right track if you meant that you'd be screening visitors to the calendar admin page by membership in your admin group for calendars.
Permissions are a much more flexible approach if you need fine granularity of control over who gets to do what to which tables. It lets you grant arbitrary privileges to particular rows for various classes of user ("group", "group with role", "registered user", etc). The UI was built explicitly for the file storage module so only supports "read/write/comment/admin" privileges, but the datamodel and PL/SQL package allows any varchar as a priv name.
ACS 4.0 abandons user groups (which have lots of problems I won't get into) in favor of a more generalized grouping scheme, and uses the general permissions model to handle things rather than use a hodge-podge like ACS 3.*. In ACS 3.* the file storage module users permissions to grant admin perms to a user, but bboard uses a special bboard admin group, etc - it's a hodge-podge due to the evolutionary development of the module in response to aD's particular client needs during individual projects.
For ACS 4.0, a core technology team with no client responsibilities was formed, so they've been able to sit back and unify stuff.
This is one of many reasons we're so eager to start porting ACS 4.0 over to OpenACS.
