aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Niemitz <>
Subject Re: Looking for feedback - Setting CommandInfo.user by default when launching tasks.
Date Tue, 29 Mar 2016 17:25:10 GMT
Re: ZK credential files, thats an interesting issue, I assume you don't
want the role user to be able to read it either, and only root or some
other privileged user?

On Tue, Mar 29, 2016 at 12:14 PM, Erb, Stephan <>

> I am in favor of your proposal. We offer less attack surface if the
> executor is not running as root.
> Interesting though, this introduces another security problem: The
> credentials file in the incoming Zookeeper  ACL patch (
> will have to be readable by
> everyone. That feels a little bit like being back to square one.
> ________________________________________
> From: Steve Niemitz <>
> Sent: Tuesday, March 29, 2016 17:34
> To:
> Subject: Looking for feedback - Setting CommandInfo.user by default when
> launching tasks.
> I've been working on some changes to how aurora submits tasks to mesos,
> specifically around Docker tasks, but I'd also like to see how people feel
> about making it more general.
> Currently, when Aurora submits a task to mesos, it does NOT set
> command.user on the ExecutorInfo, this means that mesos configures the
> sandbox (mesos sandbox that is) as root, and launches the executor
> (thermos_executor in our case) as root as well.
> What then happens is that the executor then chown()s the sandbox it creates
> to the aurora role/user, and also setuid()s the runners it forks to that
> role/user.  However, the executor itself is still running as root.
> My proposal / change is to set command.user to the aurora role by default,
> which will cause the executor to run as that user.  I've tested this
> already, and no changes are needed to the executor, it will still try to
> chown the sandbox (which is fine since it already owns it), and setuid()
> the runners it forks (again, fine, since they're already running as that
> user).
> *The controversial part of this* however is I'd like to enable this
> behavior BY DEFAULT, and allow disabling it (reverting to the current
> behavior now) via a flag to the scheduler.  My reasoning here is two fold.
>  1) It's a more secure default, preventing a compromised executor from
> doing things it shouldn't, and 2) we already have a lot of "flag bloat",
> and flags are hard enough to discover as they are.  However, I do believe
> this should be considered as a "breaking change", particularly because of
> finicky PEX extraction for the executor.
> I'd like to hear people's thoughts on this.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message