[jira] [Commented] (MESOS-9006) The agent's GET_AGENT leaks resource information when using authorization

[Benjamin Bannier (Jira)]

[ 
https://issues.apache.org/jira/browse/MESOS-9006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17136594#comment-17136594
 ] 

Benjamin Bannier commented on MESOS-9006:
-

[~dzhu], this is about leaking related to the {{VIEW_ROLE}} authorizer action. 
To see the issue reserve some resources to a role, then query the agent info 
with {{GET_AGENT}} with a principal not authorized to view that role.

> The agent's GET_AGENT leaks resource information when using authorization
> -
>
> Key: MESOS-9006
> URL: https://issues.apache.org/jira/browse/MESOS-9006
> Project: Mesos
>  Issue Type: Bug
>Reporter: Benjamin Bannier
>Priority: Critical
>  Labels: agent, integration, security
>
> While the master's {{GET_AGENTS}} call e.g., filters resources (by using an 
> approver with {{VIEW_ROLE}}) so that it does not leak resources the querying 
> principal should not be able to see, no such filtering is done in the 
> corresponding agent's {{GET_AGENT}} call.
> This call should be authorized as well to not expose information we expect to 
> be not visible.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MESOS-10133) Task launched with 0 scalar value for persistent volume.

[Andrei Sekretenko (Jira)]

[ 
https://issues.apache.org/jira/browse/MESOS-10133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17136445#comment-17136445
 ] 

Andrei Sekretenko commented on MESOS-10133:
---

Two things to check/consider here:
 - are we going to break existing frameworks by adding validation?
 - was the task actually using this volume, or was it just removed from 
resources when handling ACCEPT?

> Task launched with 0 scalar value for persistent volume.
> 
>
> Key: MESOS-10133
> URL: https://issues.apache.org/jira/browse/MESOS-10133
> Project: Mesos
>  Issue Type: Bug
>  Components: master
>Reporter: Benjamin Mahler
>Priority: Major
>
> We saw the following task launch message:
> {noformat}
> I0520 17:58:11.559875  2913 master.cpp:4985] Launching task T of framework 
> 288ebd4e-8bbf-4f2a-ac3a-2e5eb2885266 (name) with resources 
> [{"allocation_info":{"role":"role"},"disk":{"persistence":{"id":"ID","principal":"p"},"volume":{"container_path":"path","mode":"RW"}},"name":"disk","reservations":[{"labels":{"labels":[{"key":"marathon_framework_id","value":"16fa03ca-0048-4124-bdac-aff56e679c95-"},{"key":"marathon_task_id","value":"T"}]},"principal":"p","role":"role","type":"DYNAMIC"}],"scalar":{"value":0.0},"type":"SCALAR"},{"allocation_info":{"role":"role"},"name":"mem","scalar":{"value":544.0},"type":"SCALAR"},{"allocation_info":{"role":"role"},"name":"cpus","scalar":{"value":0.1},"type":"SCALAR"}]
>  on agent 16fa03ca-0048-4124-bdac-aff56e679c95-S49 at slave(1)@IP:5051 (IP) 
> on  new executor
> {noformat}
> In which the persistent volume is being used with a 0 scalar value. This 
> should have been considered invalid since we require the entire persistent 
> volume to be used, however perhaps it gets considered as not being used since 
> the value is 0 (e.g. cpus:1;foobars:0 == cpus:1).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)