On Mon, 06 Oct 2014 15:49:09 +0200 Martin Kosek <mko...@redhat.com> wrote:
> On 10/06/2014 03:01 PM, Simo Sorce wrote: > > On Mon, 06 Oct 2014 12:53:57 +0200 > > Martin Kosek <mko...@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 This one would be my preference then. Simo. > or > ipa host-allow-read-keytab/host-allow-write-keytab > > route. > > Martin -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel