[Freeipa-devel] [PATCH] 761 keytab manipulation permission management

[Martin Kosek]

On 10/06/2014 03:01 PM, Simo Sorce wrote:
> On Mon, 06 Oct 2014 12:53:57 +0200
> Martin Kosek <mkosek at redhat.com> wrote:
> 
>> On 10/06/2014 10:33 AM, Jan Cholasta wrote:
>>> Dne 3.10.2014 v 17:02 Martin Kosek napsal(a):
>>>> On 10/03/2014 04:59 PM, Jan Cholasta wrote:
>>>>> Dne 3.10.2014 v 16:47 Petr Vobornik napsal(a):
>>>>>> On 3.10.2014 16:24, Martin Kosek wrote:
>>>>>>> NACK. I will not comment on mechanics, if you get an ACK from
>>>>>>> Honza, it is good enough. I just do not like the API. It is
>>>>>>> hard to guess what "host-add-retrieve-keytab" means. That word
>>>>>>> does not even make much sense.
>>>>>>>
>>>>>>> Can we use something more readable? For example:
>>>>>>>
>>>>>>> ipa host-add-allowed-operation HOSTNAME --operation read_keys
>>>>>>> --users=STR --groups STR
>>>>>>> ipa host-add-allowed-operation HOSTNAME --operation write_keys
>>>>>>> --users=STR --groups STR
>>>>>>>
>>>>>>> and
>>>>>>>
>>>>>>> ipa host-remove-allowed-operation HOSTNAME --operation read_keys
>>>>>>> --users=STR --groups STR
>>>>>>> ipa host-remove-allowed-operation HOSTNAME --operation
>>>>>>> write_keys --users=STR --groups STR
>>>>>>>
>>>>>>> Same with services. At least to me, it looks more readable.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Martin
>>>>>>>
>>>>>>
>>>>>> Seems to me as adding of allowed operation. Not allowing an
>>>>>> operation.
>>>>>
>>>>> +1
>>>>>
>>>>>>
>>>>>> What about:
>>>>>>
>>>>>> ipa host-allow-retrieve-keytab HOSTNAME --users=STR --groups STR
>>>>>> ipa host-disallow-retrieve-keytab HOSTNAME --users=STR --groups
>>>>>> STR ipa host-allow-create-keytab HOSTNAME --users=STR --groups
>>>>>> STR ipa host-disallow-create-keytab HOSTNAME --users=STR
>>>>>> --groups STR
>>>>>
>>>>> I like these the best. Maybe with a -to or -by suffix.
>>>>>
>>>>>>
>>>>>> or if we expect more operations in a future:
>>>>>>
>>>>>> ipa host-allow-operation HOSTNAME --operation read-keys
>>>>>> --users=STR --groups STR
>>>>>> ipa host-disallow-operation HOSTNAME --operation read-keys
>>>>>> --users=STR --groups STR
>>>>>> ipa host-allow-operation HOSTNAME --operation write-keys
>>>>>> --users=STR --groups STR
>>>>>> ipa host-disallow-operation HOSTNAME --operation write-keys
>>>>>> --users=STR --groups STR
>>>>>>
>>>>>> or if we want to keep 'add' and 'remove' in command names:
>>>>>>
>>>>>> ipa host-add-retrieve-keytab-right HOSTNAME --users=STR
>>>>>> --groups=STR ipa host-add-create-keytab-right HOSTNAME
>>>>>> --users=STR --groups=STR ipa host-remove-retrieve-keytab-right
>>>>>> HOSTNAME --users=STR --groups=STR ipa
>>>>>> host-remove-create-keytab-right HOSTNAME --users=STR --groups=STR
>>>>>>
>>>>>>
>>>>>> personally I'm not a fan o the --operation switch, but could be
>>>>>> persuaded by a 'future' usage.
>>>>>
>>>>> Not a fan either, because it is not consistent with the rest of
>>>>> the framework.
>>>>> Also, non-optional options are not really options.
>>>>
>>>> Right. Though mandatory options is a concept already existing in
>>>> FreeIPA framework in many places.
>>>
>>> That does not make it right.
>>
>> Right :-)
>>
>>>> What I see as a deal breaker is that with
>>>> --operation switch, we are ready for dozens of potential future
>>>> operations. With operation hardcoded in command name, we are not.
>>>
>>> I don't see dozens of operations coming in the near future, there's
>>> no need for a premature optimization like this.
>>
>> My point was that it will be difficult to switch from having
>> per-operation commands to one general command for all operations
>> later, however far the future is.
>>
>> Given there is no clear agreement on the API (ipa
>> host-allow-operation vs.
>> host-allow-read-keytab+host-allow-write-keytab) yet, I would like to
>> ask Rob or Simo for their opinion/vote here too so that we can select
>> an approach and go with it.
> 
> I am not even sure why we are tying this to hosts to be honest.

Isn't the use case to for example allow several load balancing nodes
host/serverX.example.com get a keytab for host/server.example.com?

> The allow-operation plugin is generic, and we should probably have a
> command that reflect that like:
> ipa operations-add/mod/del and options to say what the
> operation does and what it applies to.
> 
> Of course the naming needs more thought, but I do not think having a
> command for this specific narrowed down operations is wise.
> 
> Actually it may even fit right into the permissions commands (Add a
> --operation switch ?), as these operations are just a particular type
> of ACIs/Permissions that apply to abstract operations rather than
> LDAP operations, so it is a natural extension of our permissions.
> 
> Simo.

Ok, now that's a 180° turn from what we were discussing until now... I really
do not think we can go the permission route ATM, the permission plugin is now
very bound to how ACIs work and how they are used in FreeIPA tree. Changing the
backend from ACI to ipaAllowedOperation would be something completely different.

The super-general operation-* command is interesting idea, though it decouples
these operations from their targets. I think there is a benefit in seeing an
command allowing writing/reading a keytab right in the list of host commands or
in host page Web UI. Given the short time before 4.1 release, I think it will
be more straightforward to go with

ipa host-allow-operation
or
ipa host-allow-read-keytab/host-allow-write-keytab

route.

Martin