access.properties

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

access.properties

Hayden Andrews
Hi ya,

I'm few days into the Cassandra experience and this is my first message
here :)

I've set up a dev instance of Cassandra and have got logins and access
working. Well, I thought I did, but I have found that my user that can add
and remove column families, can not insert or get the rows.

I really hope that I do not have to edit the access file to set
permissions for every user for every column family. I would like users to
either be able to update the keyspace (including any and all column
families) or only have read-only access to everything.

Since column families can be added and removed from a client app, it would
be really painfully hacky to have to write a script to update the access
file every time the client app adds or removes column families!

Anyway, some parts of my config files and a test below,


Cheers,

Hayden

Cassandra v0.7.4

cassandra.yaml:
authenticator: org.apache.cassandra.auth.SimpleAuthenticator
authority: org.apache.cassandra.auth.SimpleAuthority

access.properties:
<modify-keyspaces>=hayden
test.<rw>=hayden
test.<ro>=other,users

Now, if I login, using the cassandra-cli program, and attach to the
keyspace and then ...

[hayden@test] describe keyspace;

Keyspace: test:
  Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
    Replication Factor: 1
  Column Families:

[hayden@test] create column family potato;
[hayden@test] describe keyspace;

Keyspace: test:
  Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
    Replication Factor: 1
  Column Families:
    ColumnFamily: potato
      Columns sorted by: org.apache.cassandra.db.marshal.BytesType
      Row cache size / save period: 0.0/0
      Key cache size / save period: 200000.0/14400
      Memtable thresholds: 0.056249999999999994/12/1440
      GC grace seconds: 864000
      Compaction min/max thresholds: 4/32
      Read repair chance: 1.0
      Built indexes: []

[hayden@test] list potato;

#<User hayden groups=[]> does not have permission READ for
/cassandra/keyspaces/test/potato

Reply | Threaded
Open this post in threaded view
|

Re: access.properties

Ben Coverston
Hi Hayden,

What you are describing certainly seems useful. I am not aware of anyone
using the security features of the SimpleAuthenticator anywhere in
production. If you have a real world use case and would like to see the
authenticator improved please open a JIRA ticket. If you have something
specific in mind please contribute!

Thanks,
Ben

On 3/24/11 10:52 AM, Hayden Andrews wrote:

> Hi ya,
>
> I'm few days into the Cassandra experience and this is my first message
> here :)
>
> I've set up a dev instance of Cassandra and have got logins and access
> working. Well, I thought I did, but I have found that my user that can add
> and remove column families, can not insert or get the rows.
>
> I really hope that I do not have to edit the access file to set
> permissions for every user for every column family. I would like users to
> either be able to update the keyspace (including any and all column
> families) or only have read-only access to everything.
>
> Since column families can be added and removed from a client app, it would
> be really painfully hacky to have to write a script to update the access
> file every time the client app adds or removes column families!
>
> Anyway, some parts of my config files and a test below,
>
>
> Cheers,
>
> Hayden
>
> Cassandra v0.7.4
>
> cassandra.yaml:
> authenticator: org.apache.cassandra.auth.SimpleAuthenticator
> authority: org.apache.cassandra.auth.SimpleAuthority
>
> access.properties:
> <modify-keyspaces>=hayden
> test.<rw>=hayden
> test.<ro>=other,users
>
> Now, if I login, using the cassandra-cli program, and attach to the
> keyspace and then ...
>
> [hayden@test] describe keyspace;
>
> Keyspace: test:
>    Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
>      Replication Factor: 1
>    Column Families:
>
> [hayden@test] create column family potato;
> [hayden@test] describe keyspace;
>
> Keyspace: test:
>    Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
>      Replication Factor: 1
>    Column Families:
>      ColumnFamily: potato
>        Columns sorted by: org.apache.cassandra.db.marshal.BytesType
>        Row cache size / save period: 0.0/0
>        Key cache size / save period: 200000.0/14400
>        Memtable thresholds: 0.056249999999999994/12/1440
>        GC grace seconds: 864000
>        Compaction min/max thresholds: 4/32
>        Read repair chance: 1.0
>        Built indexes: []
>
> [hayden@test] list potato;
>
> #<User hayden groups=[]>  does not have permission READ for
> /cassandra/keyspaces/test/potato
>

--
Ben Coverston
DataStax -- The Apache Cassandra Company
http://www.datastax.com/

Reply | Threaded
Open this post in threaded view
|

Re: access.properties

Hayden Andrews
Thanks for that Ben,

Just to clarify:

The current behavior is that if a user is given access to create and
destroy column families, then they will be unable to edit/view any data in
any column family they create unless they are also specifically given
access to the new column family in the access.properties file.

Right?

Hayden :)


> Hi Hayden,
>
> What you are describing certainly seems useful. I am not aware of anyone
> using the security features of the SimpleAuthenticator anywhere in
> production. If you have a real world use case and would like to see the
> authenticator improved please open a JIRA ticket. If you have something
> specific in mind please contribute!
>
> Thanks,
> Ben
>
> On 3/24/11 10:52 AM, Hayden Andrews wrote:
>> Hi ya,
>>
>> I'm few days into the Cassandra experience and this is my first message
>> here :)
>>
>> I've set up a dev instance of Cassandra and have got logins and access
>> working. Well, I thought I did, but I have found that my user that can
>> add
>> and remove column families, can not insert or get the rows.
>>
>> I really hope that I do not have to edit the access file to set
>> permissions for every user for every column family. I would like users
>> to
>> either be able to update the keyspace (including any and all column
>> families) or only have read-only access to everything.
>>
>> Since column families can be added and removed from a client app, it
>> would
>> be really painfully hacky to have to write a script to update the access
>> file every time the client app adds or removes column families!
>>
>> Anyway, some parts of my config files and a test below,
>>
>>
>> Cheers,
>>
>> Hayden
>>
>> Cassandra v0.7.4
>>
>> cassandra.yaml:
>> authenticator: org.apache.cassandra.auth.SimpleAuthenticator
>> authority: org.apache.cassandra.auth.SimpleAuthority
>>
>> access.properties:
>> <modify-keyspaces>=hayden
>> test.<rw>=hayden
>> test.<ro>=other,users
>>
>> Now, if I login, using the cassandra-cli program, and attach to the
>> keyspace and then ...
>>
>> [hayden@test] describe keyspace;
>>
>> Keyspace: test:
>>    Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
>>      Replication Factor: 1
>>    Column Families:
>>
>> [hayden@test] create column family potato;
>> [hayden@test] describe keyspace;
>>
>> Keyspace: test:
>>    Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
>>      Replication Factor: 1
>>    Column Families:
>>      ColumnFamily: potato
>>        Columns sorted by: org.apache.cassandra.db.marshal.BytesType
>>        Row cache size / save period: 0.0/0
>>        Key cache size / save period: 200000.0/14400
>>        Memtable thresholds: 0.056249999999999994/12/1440
>>        GC grace seconds: 864000
>>        Compaction min/max thresholds: 4/32
>>        Read repair chance: 1.0
>>        Built indexes: []
>>
>> [hayden@test] list potato;
>>
>> #<User hayden groups=[]>  does not have permission READ for
>> /cassandra/keyspaces/test/potato
>>
>
> --
> Ben Coverston
> DataStax -- The Apache Cassandra Company
> http://www.datastax.com/
>
>
> !DSPAM:7,4d8baed9224092596520844!
>
>

Reply | Threaded
Open this post in threaded view
|

Re: access.properties

Ben Coverston
Looking at the code I think your assumption is correct. When you choose
the simple authority you have to explicitly set permissions.

On 3/24/11 3:50 PM, Hayden Andrews wrote:

> Thanks for that Ben,
>
> Just to clarify:
>
> The current behavior is that if a user is given access to create and
> destroy column families, then they will be unable to edit/view any data in
> any column family they create unless they are also specifically given
> access to the new column family in the access.properties file.
>
> Right?
>
> Hayden :)
>
>
>> Hi Hayden,
>>
>> What you are describing certainly seems useful. I am not aware of anyone
>> using the security features of the SimpleAuthenticator anywhere in
>> production. If you have a real world use case and would like to see the
>> authenticator improved please open a JIRA ticket. If you have something
>> specific in mind please contribute!
>>
>> Thanks,
>> Ben
>>
>> On 3/24/11 10:52 AM, Hayden Andrews wrote:
>>> Hi ya,
>>>
>>> I'm few days into the Cassandra experience and this is my first message
>>> here :)
>>>
>>> I've set up a dev instance of Cassandra and have got logins and access
>>> working. Well, I thought I did, but I have found that my user that can
>>> add
>>> and remove column families, can not insert or get the rows.
>>>
>>> I really hope that I do not have to edit the access file to set
>>> permissions for every user for every column family. I would like users
>>> to
>>> either be able to update the keyspace (including any and all column
>>> families) or only have read-only access to everything.
>>>
>>> Since column families can be added and removed from a client app, it
>>> would
>>> be really painfully hacky to have to write a script to update the access
>>> file every time the client app adds or removes column families!
>>>
>>> Anyway, some parts of my config files and a test below,
>>>
>>>
>>> Cheers,
>>>
>>> Hayden
>>>
>>> Cassandra v0.7.4
>>>
>>> cassandra.yaml:
>>> authenticator: org.apache.cassandra.auth.SimpleAuthenticator
>>> authority: org.apache.cassandra.auth.SimpleAuthority
>>>
>>> access.properties:
>>> <modify-keyspaces>=hayden
>>> test.<rw>=hayden
>>> test.<ro>=other,users
>>>
>>> Now, if I login, using the cassandra-cli program, and attach to the
>>> keyspace and then ...
>>>
>>> [hayden@test] describe keyspace;
>>>
>>> Keyspace: test:
>>>     Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
>>>       Replication Factor: 1
>>>     Column Families:
>>>
>>> [hayden@test] create column family potato;
>>> [hayden@test] describe keyspace;
>>>
>>> Keyspace: test:
>>>     Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
>>>       Replication Factor: 1
>>>     Column Families:
>>>       ColumnFamily: potato
>>>         Columns sorted by: org.apache.cassandra.db.marshal.BytesType
>>>         Row cache size / save period: 0.0/0
>>>         Key cache size / save period: 200000.0/14400
>>>         Memtable thresholds: 0.056249999999999994/12/1440
>>>         GC grace seconds: 864000
>>>         Compaction min/max thresholds: 4/32
>>>         Read repair chance: 1.0
>>>         Built indexes: []
>>>
>>> [hayden@test] list potato;
>>>
>>> #<User hayden groups=[]>   does not have permission READ for
>>> /cassandra/keyspaces/test/potato
>>>
>> --
>> Ben Coverston
>> DataStax -- The Apache Cassandra Company
>> http://www.datastax.com/
>>
>>
>> !DSPAM:7,4d8baed9224092596520844!
>>
>>

--
Ben Coverston
DataStax -- The Apache Cassandra Company
http://www.datastax.com/

Reply | Threaded
Open this post in threaded view
|

Re: access.properties

mapcar
This post has NOT been accepted by the mailing list yet.
I am also struggling with the usage of SimpleAuthority.  Is there another option available?

On a separate note, i did my own modification to SimpleAuthority.java, and made it do what i think is a more reasonable behavior, which is, if you have r/w access to the keyspace, then you also get r/w access to every CF in the keyspace.

How I contribute it into the trunk?  with a different name, of course.