[jira] [Commented] (MESOS-9349) Prevent ptracing of container management processes.
[ https://issues.apache.org/jira/browse/MESOS-9349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16661330#comment-16661330 ] James Peach commented on MESOS-9349: The plan here is to add an agent flag for operator visibility (probably the default should be enabled, so we improve security by default). We can examine the flag in the linux launcher, but from then on we can just sample and propagate the current setting. > Prevent ptracing of container management processes. > --- > > Key: MESOS-9349 > URL: https://issues.apache.org/jira/browse/MESOS-9349 > Project: Mesos > Issue Type: Bug > Components: containerization, security >Reporter: James Peach >Priority: Major > > The container launcher and the built-in executors are (at least partially) > accessible to containerized user tasks. Since these processes may contain > secrets or hold privileged resources, we can increase the difficulty of > attacking them by preventing user tasks attaching to them with ptrace(2). > This amounts to calling `prctl(PR_SET_DUMPABLE, 0)`. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MESOS-9349) Prevent ptracing of container management processes.
James Peach created MESOS-9349: -- Summary: Prevent ptracing of container management processes. Key: MESOS-9349 URL: https://issues.apache.org/jira/browse/MESOS-9349 Project: Mesos Issue Type: Bug Components: containerization, security Reporter: James Peach The container launcher and the built-in executors are (at least partially) accessible to containerized user tasks. Since these processes may contain secrets or hold privileged resources, we can increase the difficulty of attacking them by preventing user tasks attaching to them with ptrace(2). This amounts to calling `prctl(PR_SET_DUMPABLE, 0)`. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MESOS-9309) Master Healthcheck Only Returns True
[
https://issues.apache.org/jira/browse/MESOS-9309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16661061#comment-16661061
]
Joseph Wu commented on MESOS-9309:
--
You are seeing that correctly. Both the master and agent have a similar
endpoint whose only return value is {{true}}. These are purely meant to
indicate the actors are running, with no information about their state.
Metrics (i.e. {{/metrics/snapshot}}) expose more info about health.
> Master Healthcheck Only Returns True
>
>
> Key: MESOS-9309
> URL: https://issues.apache.org/jira/browse/MESOS-9309
> Project: Mesos
> Issue Type: Bug
>Reporter: Gabriel Hartmann
>Priority: Major
>
> Unless I'm reading it wrong the current [Master health
> check|https://github.com/apache/mesos/blob/master/src/master/http.cpp#L1651]
> doesn't do anything apart from return true.
> A possible candidate for a non trivial health check would be whether the
> Master has an established ZK conection.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MESOS-9293) OperationStatus messages sent to framework should include both agent ID and resource provider ID
[ https://issues.apache.org/jira/browse/MESOS-9293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bannier reassigned MESOS-9293: --- Assignee: Benjamin Bannier > OperationStatus messages sent to framework should include both agent ID and > resource provider ID > > > Key: MESOS-9293 > URL: https://issues.apache.org/jira/browse/MESOS-9293 > Project: Mesos > Issue Type: Bug >Affects Versions: 1.7.0 >Reporter: James DeFelice >Assignee: Benjamin Bannier >Priority: Major > Labels: mesosphere, operation-feedback > > Normally, frameworks are expected to checkpoint agent ID and resource > provider ID before accepting an offer with an OfferOperation. From this > expectation comes the requirement in the v1 scheduler API that a framework > must provide the agent ID and resource provider ID when acknowledging an > offer operation status update. However, this expectation breaks down: > 1. the framework might lose its checkpointed data; it no longer remembers the > agent ID or the resource provider ID > 2. even if the framework checkpoints data, it could be sent a stale update: > maybe the original ACK it sent to Mesos was lost, and it needs to re-ACK. If > a framework deleted its checkpointed data after sending the ACK (that's > dropped) then upon replay of the status update it no longer has the agent ID > or resource provider ID for the operation. > An easy remedy would be to add the agent ID and resource provider ID to the > OperationStatus message received by the scheduler so that a framework can > build a proper ACK for the update, even if it doesn't have access to its > previously checkpointed information. > I'm filing this as a BUG because there's no way to reliably use the offer > operation status API until this has been fixed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
