Xiaobao Wu created YUNIKORN-2939:
------------------------------------

             Summary: ACL check of the queue is unreasonable
                 Key: YUNIKORN-2939
                 URL: https://issues.apache.org/jira/browse/YUNIKORN-2939
             Project: Apache YuniKorn
          Issue Type: Bug
          Components: core - scheduler
            Reporter: Xiaobao Wu


I have the following queue configuration :
{code:java}
  queues.yaml: |
    partitions:
    - name: default
      queues:
      - name: root
        parent: true
        submitacl: '*'
        queues:
        - name: spark-test
          resources:
            guaranteed:
              memory: 1Gi
              vcore: "1"
            max:
              memory: 40Gi
              vcore: "10"
          submitacl: 'master'
      placementrules:
      - name: tag
        create: true
        value: namespace {code}
I found that when I set the *root* submitacl to ' * ', the *root.spark-test* 
submitacl seems to be invalid and seems to allow any user to submit. After I 
looked at the code, I found a strange logical check of queue permissions :
{code:java}
func (sq *Queue) CheckSubmitAccess(user security.UserGroup) bool {
    if common.IsRecoveryQueue(sq.QueuePath) {
       // recovery queue can never pass ACL checks
       return false
    }
    sq.RLock()
    allow := sq.submitACL.CheckAccess(user) || sq.adminACL.CheckAccess(user)
    sq.RUnlock()
    if !allow && sq.parent != nil {
       allow = sq.parent.CheckSubmitAccess(user)
    }
    return allow
} {code}
It can be seen that if the current subqueue does not allow the user to submit 
jobs to this subqueue, it will recursively check its parent queue. I think this 
is unreasonable, why the priority of the user rights of the parent queue is 
higher than that of the child queue, which will cause some user rights 
management problems.

 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to