cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (CLOUDSTACK-8562) User Definable Roles
Date Wed, 20 Apr 2016 08:33:25 GMT


ASF GitHub Bot commented on CLOUDSTACK-8562:

Github user bhaisaab commented on a diff in the pull request:
    --- Diff: engine/schema/src/org/apache/cloudstack/acl/ ---
    @@ -0,0 +1,109 @@
    +// Licensed to the Apache Software Foundation (ASF) under one
    +// or more contributor license agreements.  See the NOTICE file
    +// distributed with this work for additional information
    +// regarding copyright ownership.  The ASF licenses this file
    +// to you under the Apache License, Version 2.0 (the
    +// "License"); you may not use this file except in compliance
    +// with the License.  You may obtain a copy of the License at
    +// Unless required by applicable law or agreed to in writing,
    +// software distributed under the License is distributed on an
    +// KIND, either express or implied.  See the License for the
    +// specific language governing permissions and limitations
    +// under the License.
    +package org.apache.cloudstack.acl;
    +import javax.persistence.Column;
    +import javax.persistence.Entity;
    +import javax.persistence.EnumType;
    +import javax.persistence.Enumerated;
    +import javax.persistence.GeneratedValue;
    +import javax.persistence.GenerationType;
    +import javax.persistence.Id;
    +import javax.persistence.Table;
    +import java.util.UUID;
    +@Table(name = "role_permissions")
    +public class RolePermissionVO implements RolePermission {
    --- End diff --
    @koushik-das okay I got what you're saying, but it's not possible. Also see we've to be
backward compatible with the static checker, so (1) the order of processing of rules need
to be similar to the static-checker which is first allow rules then deny checks, then finally
annotation and lastly deny all, (2) rules can be both apiname or wildcards such as list\*
therefore we cannot have the references reversed or what you're suggesting, (3) the model
promotes explicit rules than implicit declarations for security and various use-case (so we
don't assume anything), (4) if we want an API like deployVM to be available for all or some
role types we can use the authorized field in the API annotation (for example using authorized={RoleType.Admin,
RoleType.User ... etc} will enable this API for all when no explicit rules are set by the
    I've thought this through but this is the best model we can have trading feature use,
functionality and security. Provided this, do you have suggestion if we can improve this.?

> User Definable Roles
> --------------------
>                 Key: CLOUDSTACK-8562
>                 URL:
>             Project: CloudStack
>          Issue Type: New Feature
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Management Server
>            Reporter: Paul Angus
>            Assignee: Rohit Yadav
> Static moved to database and made user definable

This message was sent by Atlassian JIRA

View raw message