[
https://issues.apache.org/jira/browse/MESOS-7222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Mann updated MESOS-7222:
-----------------------------
Description:
The Mesos master/agent code currently loads separate instances of an
authenticator module for each realm that it's installed into.
{{initializeHttpAuthenticators()}} is [called multiple
times|https://github.com/apache/mesos/blob/a310bcc10b872b44fe6083756030daa96c21d141/src/master/master.cpp#L599-L638],
and each invocation [creates an
instance|https://github.com/apache/mesos/blob/a310bcc10b872b44fe6083756030daa96c21d141/src/common/http.cpp#L987-L988]
of the module.
It would be better to create a singleton of each authenticator module. These
could be stored in a map, indexed by the module name. Note that libprocess's
{{setAuthenticator()}} helper currently accepts an {{Owned<Authenticator>}} and
takes ownership of each module instance. In order to pass ownership of
authenticator singletons to libprocess, {{setAuthenticator}} could be changed
to something like the following:
{code}
Future <Nothing> setAuthenticator(
const map<string, Owned<Authenticator>> authenticators,
const map<string, string> authenticatorRealms);
{code}
Note that the current situation would cause a legitimate bug in the case of a
stateful authenticator module which is dynamically updated at runtime. This
could lead to inconsistent state across the module instances, when the author
intended for them to share a single global state.
was:
The Mesos master/agent code currently loads separate instances of an
authenticator module for each realm that it's installed into.
{{initializeHttpAuthenticators()}} is [called multiple
times|https://github.com/apache/mesos/blob/a310bcc10b872b44fe6083756030daa96c21d141/src/master/master.cpp#L599-L638],
and each invocation [creates an
instance|https://github.com/apache/mesos/blob/a310bcc10b872b44fe6083756030daa96c21d141/src/common/http.cpp#L987-L988]
of the module.
It would be better to create a singleton of each authenticator module. These
could be stored in a map, indexed by the module name. Note that libprocess's
{{setAuthenticator()}} helper currently accepts an {{Owned<Authenticator>}} and
takes ownership of each module instance. In order to pass ownership of
authenticator singletons to libprocess, {{setAuthenticator}} could be changed
to something like the following:
{code}
Future <Nothing> setAuthenticator(
const map<string, Owned<Authenticator>> authenticators,
const map<string, string> authenticatorRealms);
{code}
> Load authenticator modules as singletons
> ----------------------------------------
>
> Key: MESOS-7222
> URL: https://issues.apache.org/jira/browse/MESOS-7222
> Project: Mesos
> Issue Type: Improvement
> Components: security
> Reporter: Greg Mann
> Labels: authentication, libprocess, mesosphere, tech-debt
>
> The Mesos master/agent code currently loads separate instances of an
> authenticator module for each realm that it's installed into.
> {{initializeHttpAuthenticators()}} is [called multiple
> times|https://github.com/apache/mesos/blob/a310bcc10b872b44fe6083756030daa96c21d141/src/master/master.cpp#L599-L638],
> and each invocation [creates an
> instance|https://github.com/apache/mesos/blob/a310bcc10b872b44fe6083756030daa96c21d141/src/common/http.cpp#L987-L988]
> of the module.
> It would be better to create a singleton of each authenticator module. These
> could be stored in a map, indexed by the module name. Note that libprocess's
> {{setAuthenticator()}} helper currently accepts an {{Owned<Authenticator>}}
> and takes ownership of each module instance. In order to pass ownership of
> authenticator singletons to libprocess, {{setAuthenticator}} could be changed
> to something like the following:
> {code}
> Future <Nothing> setAuthenticator(
> const map<string, Owned<Authenticator>> authenticators,
> const map<string, string> authenticatorRealms);
> {code}
> Note that the current situation would cause a legitimate bug in the case of a
> stateful authenticator module which is dynamically updated at runtime. This
> could lead to inconsistent state across the module instances, when the author
> intended for them to share a single global state.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
