[Freeipa-devel] [PATCH] 581 remove enrolledBy when unenrolled

Rob Crittenden rcritten at redhat.com
Sat Oct 23 01:45:29 UTC 2010


Simo Sorce wrote:
> On Wed, 20 Oct 2010 17:14:56 -0400
> Rob Crittenden<rcritten at redhat.com>  wrote:
>
>> Rob Crittenden wrote:
>>> Dmitri Pal wrote:
>>>> Simo Sorce wrote:
>>>>> On Fri, 15 Oct 2010 17:27:07 -0400
>>>>> Rob Crittenden<rcritten at redhat.com>  wrote:
>>>>>
>>>>>
>>>>>> Remove the enrolledBy when a host is unenrolled (which is the
>>>>>> same as disabling the host).
>>>>>>
>>>>>> ticket 301
>>>>>>
>>>>>> rob
>>>>>>
>>>>>
>>>>> nack, if host can write enrolledBy it can fake info
>>>>>
>>>>> Simo.
>>>>>
>>>>>
>>>> I agree. I think it should be "delete" rather than "write".
>>>>
>>>
>>> The delete permission is for entries, not for attributes.
>>>
>>> I'll need to ask the 389-ds guys about how to do this, though I
>>> think it may be via an attr value aci which will require some work
>>> in our aci plugin because it doesn't currently support them.
>>>
>>> rob
>>
>> Updated patch to clear out enrolledBy when a host is unenrolled.
>>
>> This uses a targattrfilters aci that says that enrolledBy can be
>> deleted if it is not empty. We also require that krblastpwddchange be
>> empty, so you can't simply delete enrolledby on an enrolled host.
>>
>> host-disable first deletes the principalkey and lastpwdchange and then
>> removes the enrollment.
>>
>> ticket 301
>
> This patch looks good but I was a bit surprised to see that you use
> krblastpwdchange as a trigger. Why not the principal key ?

Because we can't read the principal key (by design).

>
> Also if I read it right
> (targattrfilters="del=enrolledby:(enrolledBy=*)") allows you to
> delete enrolledBy but not to change it to another value.
> This prevents misrepresenting who enrolled the host, but still allows
> the host to remove the information (the host can remove
> krblastpwdchange first and then re-add it right ?)

Yes, I suppose that's possible.

>
> So I am wondering if we really solve all relevant abuses with
> this patch (some of it is solved) or if we are still leaving the door
> open to something.
>
> Simo.
>

Ok, I'll reconsider this some more.

rob




More information about the Freeipa-devel mailing list