Re: [cpx] Vanity Domain / E-mail Only

[Ricardo Newbery <newbery@xxxxxxxxxxx>]

At 1:25 PM -0700 2/17/06, Scott Wiersdorf wrote:
> On Fri, Feb 17, 2006 at 12:07:30PM -0800, Ricardo Newbery wrote:
> >  This is good to know.  Will this increased flexibility extend to
> >  allow the separation-of-roles configuration as discussed in an
> >  earlier post?
> >
> >  To recap...
> >  I want to be able to set up a Domain Admin account that can log into
> >  CPX to do all the Domain Admin stuff *except* manage the domain's web
> >  space files and an end user account that owns/manages the web space
> >  files for the domain.  And I want to be able to disable Mail, FTP,
> >  and Shell privileges on the Domain Admin account while still allowing
> >  the account to grant these privileges to the end user accounts.
> >
> >
> >  Server Admin
> >    |
> >    |---- Domain Admin
> >    |       |
> >    |       |---- Domain Web Admin
> >    |       |
> >    |       |---- Domain End User
> >    |       |
> >    |       |---- Domain End User
> >
> >
> >  Will the new design allow such a setup?
>
> Hi Ric,
>
> I don't know the specifics of the next design revision for CPX, but we
> will certainly look at this. I believe your setup could be
> accomplished with the existing CPX setup plus a DAV setup (see
> http://scott.wiersdorf.org/blog/sysadmin/mod_dav.html).


I've done WebDAV setups before.  I'm assuming you are suggesting just 
setting up WebDAV access to the Domain Admin's web file space.  Okay, 
I guess that will work.  But ever try explaining WebDAV to your 
average non-webtech-savvy client?

Alternately, I guess I could also just set up yet another file 
management web app in addition to CPX but again... one more app to 
explain, train, and support.  This is the solution I'm currently 
leaning toward.

A CPX integrated solution would be much easier to demonstrate and to 
train people how to use.




> To address the real concern, though, I think we'll likely not add any
> more roles, but treat *some* of the role functions as additional
> features or services that can be granted to end users. E.g., "allow
> end user to manage mail aliases for this domain", etc. That would be
> my vote, in any case.


I'm not sure I understand.  Users, groups, roles, role functions, 
permissions, privileges, features, services.  These terms mean 
different things in different security environments.  Whether we're 
talking about adding more roles or enabling additional features, 
services, or permissions that can be granted to end users, the end 
result is what is important.

I'm sort of a fan of the super-flexible security model that Zope uses 
in its framework but I can understand not wanting to try to reproduce 
this model in CPX.  In any case, perhaps because of my Zope bias, my 
concept of *role* is that this is just a convenient way to allocate 
"permissions".  Zope permissions are used as very specific guards on 
actions or access to methods, scripts, and other Zope objects.  Users 
can be assigned multiple roles.  Multiple users can be assigned the 
same role.  Again, this may not be a practical model for CPX but it 
helps to get these definitions out there before we discuss 
alternative models.

So what is the CPX security model?  I'm going to try to define this. 
Please correct me where necessary...

Looks like we've got "Users", "Domains", "User Types", "Privileges", 
and "Features/Services".

A CPX "User" is just your standard Unix user.

A CPX "Domain" is just a way to associate users with a specific 
domain name.  Individual users can be associated with only one domain.

A CPX "User Type" appears to be an exclusive collection of "users". 
In my previous messages, I think I erred in using the term "roles" 
synonymously with "user types".  In Zope a role is a non-exclusive 
collection of *permissions*.  In contrast, a CPX user type appears to 
be an exclusive collection of *users*.  There are three CPX user 
types: Server Admin, Domain Admin, and End User.  These are exclusive 
collections because each user can be assigned to only one user type. 
Additionally, there can be only one Server Admin user per server and 
only one Domain Admin user per domain.

CPX "Privileges" are just the combination of your standard Unix 
privileges (shell, ftp, mail) and the special CPX "file management" 
privilege.

CPX "Features/Services" are any additional features or services 
provided by the CPX interface, not covered by CPX privileges.  These 
include the features/services that are automatically granted to 
Server Admins and Domain Admins.  Server Admins can add/edit Domain 
Admins, add/edit End Users, and add/edit Domains.  Domain Admins can 
add/edit End Users, manage email addresses, and manage the domain's 
web file space.


Okay... so, assuming this description of the CPX security model is 
accurate, let me try to suggest a possible solution.

As a Server Admin, when you add a domain, you are given the option to 
assign the domain to a previously defined User.  This user then 
becomes the Domain Admin for that Domain.  A useful option here would 
be a second optional user field in case you want to assign a 
different user to 'own' the domain's web files from the user assigned 
to be the Domain Admin.  This makes it possible to assign the "manage 
web files" feature at domain creation time a bit more flexibly and 
also conveniently solves the quota allocation side issue at the same 
time.

This option seems like it can be added without doing any violence to 
the CPX model.  Any thoughts?

Ric

======================================================================
This is <cpx@xxxxxxxxxxxxx>      <http://www.groupmail.org/lists/cpx/>
Before posting a question, please search the archives (see above URL).