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 <stephan....@blue-yonder.com> wrote: > 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 ( > https://reviews.apache.org/r/45042/) will have to be readable by > everyone. That feels a little bit like being back to square one. > ________________________________________ > From: Steve Niemitz <sniem...@apache.org> > Sent: Tuesday, March 29, 2016 17:34 > To: dev@aurora.apache.org > 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. >
