On 6.10.2014 15:49, Martin Kosek 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
or
ipa host-allow-read-keytab/host-allow-write-keytab

route.

Martin


It also works a bit differently. Permissions defined by admin, using a permission plugin, are part of RBAC. Allowed operations aren't. Binding it with permission plugin might cause confusion.

On the other hand, I'm afraid that current implementation clutters up both CLI and Web UI. We don't distinguish common commands and less used ones. Therefore they all are equally visible - not good UX. We will have to focus on this issue sooner or later.

The general operaion-* commands might be a subject of discussion. I don't like it because the operations are always bound with particular object.

I agree with Martin and would go with 'ipa host-allow-read-keytab/host-allow-write-keytab' commands.

Also terminology is not united: write vs create + read vs retrieve. Since ipa-get-keytab uses --retrieve, I would go with 'create' and 'retrieve'.
--
Petr Vobornik

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to