Etcd: Incorrect Usage: flag provided but not defined: -prefix

Created on 2 Apr 2019  路  9Comments  路  Source: etcd-io/etcd

Hello,

I successfully setup an etcd cluster (v3.2 on Ubuntu Server 18.04) and have been able to interact with it on a basic level via etcdctl with SSL/TLS and ETCDCTL_API=2.
I followed the documentation provided on github to the letter and so far it has worked very well. However, I've been getting errors while trying to grant read/write permissions to a role based on a prefix, the error message reads:

Incorrect Usage: flag provided but not defined: -prefix

By trial and error I've noticed that some of the etcdctl command options referred on the documentation are incorrect or not what the tool is expecting (at least for v3.2).

For example:
Your documentation suggest
etcdctl role grant-permission myrolename readwrite /foo
but instead only accepts
role grant --rw --path /foo myrolename

If I try to use
etcdctl role grant-permission myrolename --prefix=true readwrite /foo/
or what I thought could be valid alternatives
role grant --rw --path /foo/ --prefix=yes myrolename
role grant --rw --prefix --path /foo/ --prefix myrolename

I keep getting the above mentioned error. I'm not sure which command options are valid and which are not. Is the --prefix flag still available or not?

Please, assist on how to correctly use the flags to grant R/W permissions recursively or utilizing a prefix. Also, please update the documentation with current ways to use the tool or provide a link where to read the correct one.

Thanks in advance.

aredoc arequestion stale

All 9 comments

etcdctl role grant-permission test readwrite /foo and etcdctl role grant-permission test --prefix=true readwrite /foo/ works fine for me on etcd 3.3 - 2019-04-02 20:38:33.326745 N | auth: role test's permission of key /foo is updated as READWRITE. What's the error that you get on etcdctl role grant-permission test readwrite /foo ? What is the output of etcdctl role --help? Thanks!

@spzala I'm using etcd v3.2.17 as provided by Ubuntu 18.04LTS:
https://packages.ubuntu.com/bionic/etcd-server
https://packages.ubuntu.com/bionic/etcd-client

To be more specific on my intentions, let me give you a bit of a background. I'm working with Patroni (https://github.com/zalando/patroni) a tool to setup a highly available PostgreSQL cluster. Patroni saves the cluster configuration on etcd under the following structure:

/postgresql-common
/postgresql-common/11-main
/postgresql-common/11-main/config
/postgresql-common/11-main/leader
/postgresql-common/11-main/optime
/postgresql-common/11-main/optime/leader
/postgresql-common/11-main/sync
/postgresql-common/11-main/history
/postgresql-common/11-main/members
/postgresql-common/11-main/members/pg-server-001
/postgresql-common/11-main/initialize

I have authentication enabled in etcd with a root user and a password as described in the documentation. I executed Patroni's initialization with the root user:password combination previously created. It all runs fine as long as it's done with the etcd root user.

On etcd, I created a new role "PGconfigAdmin" and a new user "patroni" with a password. When I try to grant permissions to the new role using
role grant-permission PGconfigAdmin readwrite --prefix=true /postgresql-common/
I get the following message back No help topic for 'grant-permission'

That's how I realized etcdctl was not accepting the command options described in the documentation (either the site or github). So, I read through the command options with etcdctl role -h and found out that grant-permission is no longer available, instead the new syntax is
role grant --rw --path /foo/ myrolename without --prefix=true
If I try to include the prefix variable, either as --prefix=true or as a logical flag --prefix I get the error

Incorrect Usage: flag provided but not defined: -prefix

Here is the output of etcdctl role -help with ETCDCTL_API=2

NAME:
etcdctl role - role add, grant and revoke subcommands
USAGE:
etcdctl role command [command options] [arguments...]
COMMANDS:
add - add a new role for the etcd cluster
get - get details for a role
list - list all roles
remove - remove a role from the etcd cluster
grant - grant path matches to an etcd role
revoke - revoke path matches for an etcd role
OPTIONS:
--help, -h show help

And the output for etcdctl role grant -help with ETCDCTL_API=2

NAME:
etcdctl role grant - grant path matches to an etcd role
USAGE:
etcdctl role grant [command options]
OPTIONS:
--path value Path granted for the role to access
--read Grant read-only access
--write Grant write-only access
--readwrite, --rw Grant read-write access

Either your backwards compatibility is totally skewed or I'm doing something wrong.

Thanks for the details. On etcd 3.3 v3 API I have, both grant and grant-permission works fine and backward compatible to me. The role --help output:

COMMANDS:
    add         Adds a new role
    delete          Deletes a role
    get         Gets detailed information of a role
    grant-permission    Grants a key to a role
    list            Lists all roles
    revoke-permission   Revokes a key from a role

Per the doc links I sent you earlier the v2 seems only supported grant as you could see in your environment. I could be wrong, copying @hexfusion @gyuho for their thoughts. Thanks!

@spzala thanks for the information. I'm not worried about differences in the syntax between v2 and v3, what bothers me the most is the missing --prefix=true functionality or a way to achieve the same. If I have a long namespace with a deep structure, a --prefix=true becomes really handy to provide permissions to the role that will use it. Otherwise is pure inconvenient because I have to let the app/service using etcd create the structure with the root user, then read that structure and grant permissions to a service specific role via a script.

I am not sure of --prefix=truesupport in the v2. Let's wait to have someone else pitch in. Thanks!

It looks as if in 3.3.13, the default is now API 2, contrary to what the README claims. I have to set ETCDCTL_API=3 to get the new API.

In 3.3, default is still API V2. We should clarify in that doc.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions.

Was this page helpful?
0 / 5 - 0 ratings