[et-mgmt-tools] Cobbler and the ownership module, question about policies?

[Michael DeHaan]

Bryan Kearney wrote:
>
>
> Michael DeHaan wrote:
>> So,
>>
>> Warning -- technical email :)
>>
>> I have a pretty good ownership module going for Cobbler now 
>> (https://fedorahosted.org/cobbler/wiki/CustomizableAuthorization), 
>> that allows you to say that objects are owned by certain users and/or 
>> groups, and prevents users not in those groups (except for an admin 
>> group) to be able to edit those objects.   This is designed for very 
>> large organizations that may want lab admins to control certain 
>> profiles, but not all of them (for instance, a build lab versus a 
>> test lab versus a production datacenter, etc).
>> In this implementation, users in the admin group have access to all 
>> objects always, and by default all objects are created with no 
>> editing restrictions unless the creator decides to lock them 
>> down.      The command line has none of these restrictions so you can 
>> always recover/reconfigure things with root if you find you've 
>> somehow locked yourself out.   (It's also coded up so you can't use 
>> the WebUI to remove your own access from an object).
>>
>> There are a couple of policy questions for this dealing with some of 
>> the corner cases.
>>
>> (A) What to do about kickstart editing in the WebUI.   This is the 
>> "fun" corner case to figure out.
>>
>> The WebUI contains a very basic kickstart template editor (it's just 
>> a text field for now). Possible Answer1? I think the solution is that 
>> a kickstart template file can be edited if the user editing it is 
>> allowed to edit ALL profiles/systems making use of it.  This is a bit 
>> of a catch 22 as it would be possible to create a system using a 
>> template file, just for the purpose of making that user not be able 
>> to edit it.  This shouldn't happen but is technically possible.
>> Possible Answer2 -- If you're not in the admin group, you can't edit 
>> kickstart template files at all.
>>
>> Possible Answer3 -- Remove kickstart editing from the WebUI, and 
>> encourage users to create kickstart templates where they have 
>> filesystem access (i..e their home directories)
>
> For testing, I have liked the ability to edit he ks file and not need 
> to log into the box. If possible, please keep it. It may be heinous, 
> but is there a model where each ks has a security item associated to 
> it (e.g. a role) or ks files can be grouped and a role associated to 
> the group?

The ownership module is off by default, so if we removed it, it might 
only be for that.    I think we can find a workable solution though :)

I'm trying to avoid creating an additional cobbler object wrapping the 
kickstarts -- as that ends up creating too many Cobbler objects and 
makes things less simpler for newer users (who have this feature turned 
off by default, anyway).

>>
>> ----
>>
>> (B) What do to about "orphanage".
>>
>> If UserA owns ProfileA, and UserB owns SystemB, which depends on 
>> ProfileB, what happens if UserA wants to delete ProfileA?
>>
>> Answer?   The profile cannot be deleted.
>>
>> If UserA owns ProfileA, and UserB owns SubprofileB, what happens when 
>> UserA wants to delete ProfileA?
>>
>> Answer?   I think the answer is Subprofile B is promoted to a full 
>> profile with all of the inherited fields set to the values of Profile A.
>> However this is complicated and confusing so "No deletion allowed" 
>> may be the better route.
>
> First cut, no delete. Every time i have used nested profiles it was 
> becuase I had nested logic in the kickstart file. So. promoting a 
> subprofile would cause the subprofile to break.

I agree.   Though it might not cause breakage if we promote the 
attributes that are marked "inherit", it's clearly non-obvious behavior 
to the user.
The admin could always intervene and blow away all objects below it if 
required.


>>
>> ---
>>
>> (C) FYI...
>>
>> Everyone is allowed to run "cobbler sync" if they can authenticate.  
>> I don't think this should be a problem.
>>
>> Also, if you're in, you can read everything, you just might not be 
>> able to /write/ everything.   This also should not be a problem as 
>> provisioning
>> data is basically public if you want to use it in a Fully Automated 
>> Context anyway.
>>
>> Currently settings, modules.conf, and users.conf can't be edited 
>> through the WebUI as that's a really good way to lock yourself out of 
>> the WebUI
>> altogether :)
>>
>> ---
>>
>> Any thoughts on the above from those who have a vested interest in 
>> controlling access to cobbler objects through the WebUI?
>> Remember this is all off by default and is only there if you want it 
>> -- but if you want it, I want to make sure this fits your 
>> organizational needs.
>>
>> --Michael
>>
>> _______________________________________________
>> et-mgmt-tools mailing list
>> et-mgmt-tools at redhat.com
>> https://www.redhat.com/mailman/listinfo/et-mgmt-tools
>
> _______________________________________________
> et-mgmt-tools mailing list
> et-mgmt-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/et-mgmt-tools