[jira] [Created] (MESOS-8909) Scrubbing value secret from HTTP responses
Zhitao Li created MESOS-8909: Summary: Scrubbing value secret from HTTP responses Key: MESOS-8909 URL: https://issues.apache.org/jira/browse/MESOS-8909 Project: Mesos Issue Type: Task Components: security Reporter: Zhitao Li Mesos supports a value based secret. However, I believe some HTTP endpoints and v1 operator responses could leak this information. The goal here is to make sure these endpoints do not leak the information. We did some quick research and gather the following list in this [Google doc|https://docs.google.com/document/d/1W26RUpYEB92eTQYbACIOem5B9hzXX59jeEIT9RB2X1o/edit#heading=h.gzvg4ec6wllm]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MESOS-8908) Add -fno-omit-frame-pointer to improve debugging and profiling.
[
https://issues.apache.org/jira/browse/MESOS-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472687#comment-16472687
]
Benjamin Mahler commented on MESOS-8908:
Linking in MESOS-6229, as there was some discussion between
[~jpe...@apache.org] and [~bbannier] on https://reviews.apache.org/r/52695/.
{{-fno-omit-frame-pointer}} was slated for a follow up patch but it looks like
that didn't manifest.
> Add -fno-omit-frame-pointer to improve debugging and profiling.
> ---
>
> Key: MESOS-8908
> URL: https://issues.apache.org/jira/browse/MESOS-8908
> Project: Mesos
> Issue Type: Improvement
> Components: build, libprocess, stout
>Reporter: Benjamin Mahler
>Priority: Major
>
> Currently, we build without {{-fno-omit-frame-pointer}} which is needed to
> get reliable stack traces. Without this, obtaining {{perf}} profiles from
> users is not reliable:
> http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html#C
> Apparently, the performance win from frame pointer omission is very minor and
> many projects opt to disable the optimization given the benefits to debugging
> and profiling.
> I tried the {{--call-graph dwarf}} "workaround" for perf but still
> experienced {{[unknown]}} stack frames and what looked to be missing frames:
> http://www.brendangregg.com/perf.html#StackTraces (see dwarf section)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MESOS-8908) Add -fno-omit-frame-pointer to improve debugging and profiling.
Benjamin Mahler created MESOS-8908:
--
Summary: Add -fno-omit-frame-pointer to improve debugging and
profiling.
Key: MESOS-8908
URL: https://issues.apache.org/jira/browse/MESOS-8908
Project: Mesos
Issue Type: Improvement
Components: build, libprocess, stout
Reporter: Benjamin Mahler
Currently, we build without {{-fno-omit-frame-pointer}} which is needed to get
reliable stack traces. Without this, obtaining {{perf}} profiles from users is
not reliable:
http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html#C
Apparently, the performance win from frame pointer omission is very minor and
many projects opt to disable the optimization given the benefits to debugging
and profiling.
I tried the {{--call-graph dwarf}} "workaround" for perf but still experienced
{{[unknown]}} stack frames and what looked to be missing frames:
http://www.brendangregg.com/perf.html#StackTraces (see dwarf section)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MESOS-6229) Default to using hardened compilation flags
[
https://issues.apache.org/jira/browse/MESOS-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472650#comment-16472650
]
Benjamin Mahler commented on MESOS-6229:
Was hoping to introduce {{-fno-omit-frame-pointer}} and came across this
ticket. Looks like that particular flag wasn't introduced? Any reason?
> Default to using hardened compilation flags
> ---
>
> Key: MESOS-6229
> URL: https://issues.apache.org/jira/browse/MESOS-6229
> Project: Mesos
> Issue Type: Improvement
>Reporter: Aaron Wood
>Assignee: Aaron Wood
>Priority: Minor
> Labels: c++, clang, gcc, security
> Fix For: 1.2.0
>
>
> Provide a default set of hardened compilation flags to help protect against
> overflows and other attacks. Apply to libprocess and stout as well. Current
> set of flags that were discussed on slack to implement:
> -Wformat-security
> -Wstack-protector
> -fstack-protector-strong (-fstack-protector-all might be overkill, it could
> be more effective to use this. Requires gcc >= 4.9 which should be
> reasonable. Detect compiler support and use what we can but prefer
> -fstack-protector-strong)
> -pie
> -fPIE
> -fPIC
> -D_FORTIFY_SOURCE=2
> -Wl,-z,relro,-z,now (currently not a part of the patch, this should be
> another JIRA)
> -fno-omit-frame-pointer
> https://reviews.apache.org/r/52645/
> https://reviews.apache.org/r/52695/
> https://reviews.apache.org/r/52696/
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MESOS-8904) Master crash when removing quota.
[
https://issues.apache.org/jira/browse/MESOS-8904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Mann reassigned MESOS-8904:
Assignee: Greg Mann
> Master crash when removing quota.
> -
>
> Key: MESOS-8904
> URL: https://issues.apache.org/jira/browse/MESOS-8904
> Project: Mesos
> Issue Type: Bug
> Components: master
>Affects Versions: 1.3.2, 1.4.1, 1.5.0, 1.6.0
>Reporter: Benjamin Mahler
>Assignee: Greg Mann
>Priority: Blocker
>
> The allocator can crash when quota is removed due to a race between the
> removal and the quota_allocated metric computation. If the metric dispatches
> before the quota removal can remove the metric, then this crash occurs:
> {noformat}
> May 10 20:15:28 int-master1.sanitized.mesosphe.re mesos-master[7189]: F0510
> 20:15:28.821099 7205 sorter.cpp:395] Check failed: 'find(clientPath)' Must
> be non NULL
> May 10 20:15:28 int-master1.sanitized.mesosphe.re mesos-master[7189]: ***
> Check failure stack trace: ***
> May 10 20:15:28 int-master1.sanitized.mesosphe.re mesos-master[7189]: @
> 0x7fd7d843bdcd google::LogMessage::Fail()
> May 10 20:15:28 int-master1.sanitized.mesosphe.re mesos-master[7189]: @
> 0x7fd7d843dbfd google::LogMessage::SendToLog()
> May 10 20:15:29 int-master1.sanitized.mesosphe.re mesos-master[7189]: @
> 0x7fd7d843b9bc google::LogMessage::Flush()
> May 10 20:15:29 int-master1.sanitized.mesosphe.re mesos-master[7189]: @
> 0x7fd7d843e4f9 google::LogMessageFatal::~LogMessageFatal()
> May 10 20:15:29 int-master1.sanitized.mesosphe.re mesos-master[7189]: @
> 0x7fd7d791f79d google::CheckNotNull<>()
> May 10 20:15:29 int-master1.sanitized.mesosphe.re mesos-master[7189]: @
> 0x7fd7d791a3c4
> mesos::internal::master::allocator::DRFSorter::allocationScalarQuantities()
> May 10 20:15:29 int-master1.sanitized.mesosphe.re mesos-master[7189]: @
> 0x7fd7d7900bc9
> mesos::internal::master::allocator::internal::HierarchicalAllocatorProcess::_quota_allocated()
> May 10 20:15:29 int-master1.sanitized.mesosphe.re mesos-master[7189]: @
> 0x7fd7d79182f9
> _ZNSt17_Function_handlerIFvPN7process11ProcessBaseEESt5_BindIFZNS0_8dispatchIdN5mesos8internal6master9allocator8internal28HierarchicalAllocatorProcessERKSsSD_SD_SD_EENS0_6FutureIT_EERKNS0_3PIDIT0_EEMSI_FSF_T1_T2_EOT3_OT4_EUlRSsSU_S2_E_SsSsSt12_PlaceholderILi1E9_M_invokeERKSt9_Any_dataS2_
> May 10 20:15:29 int-master1.sanitized.mesosphe.re mesos-master[7189]: @
> 0x7fd7d83a6eac process::ProcessManager::resume()
> May 10 20:15:29 int-master1.sanitized.mesosphe.re mesos-master[7189]: @
> 0x7fd7d83ac826
> _ZNSt6thread5_ImplISt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUlvE_vEEE6_M_runEv
> May 10 20:15:29 int-master1.sanitized.mesosphe.re mesos-master[7189]: @
> 0x7fd7d63d12b0 (unknown)
> May 10 20:15:29 int-master1.sanitized.mesosphe.re mesos-master[7189]: @
> 0x7fd7d5befe25 start_thread
> May 10 20:15:29 int-master1.sanitized.mesosphe.re mesos-master[7189]: @
> 0x7fd7d591d34d __clone
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MESOS-8219) Validate that any offer operation is only applied on resources from a single provider
[
https://issues.apache.org/jira/browse/MESOS-8219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472122#comment-16472122
]
Gilbert Song commented on MESOS-8219:
-
Should the fixVersion includes 1.6.0?
> Validate that any offer operation is only applied on resources from a single
> provider
> -
>
> Key: MESOS-8219
> URL: https://issues.apache.org/jira/browse/MESOS-8219
> Project: Mesos
> Issue Type: Task
> Components: master
>Reporter: Benjamin Bannier
>Assignee: Jan Schlicht
>Priority: Major
> Fix For: 1.5.1
>
>
> Offer operations can only be applied to resources from one single resource
> provider. A number of places in the implementation assume that the provider
> ID obtained from any {Resource} in an offer operation is equivalent to the
> one from any other resource. We should update the master to validate that
> invariant and reject malformed operations.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
