Run tasks with their own user context. #77
Conversation
walac
changed the title
| // in in a development environment, so do not fail the task to tests | ||
| // run successfully. | ||
| u := user{} | ||
| if err = u.create(); err != nil { |
There was a problem hiding this comment.
So I think that this can be rather dangerous. If for some reason creating a user fails, this could be run under escalated permissions without knowing it.
I think it should be an either/or thing. Either the engine is configured to run a process under a temp user and fails if that user can't be used, or the engine is configured to not create a temp user and run under the worker user.
There was a problem hiding this comment.
Thinking about it a little more, i wonder if it would be possible to have the engine configuration option to either use a module for creating the user, or using the user that the engine is running under. If that config setting says to create a user using some other module, then this .create() stuff can be called and the user returned from that used for the process. Also would allow someone to specify different creation scripts depending on need. Like if there are some special groups that the user should be part of on one type of worker type but not another.
What do you think?
There was a problem hiding this comment.
As we talked earlier, I implemented a environment variable based configuration. If TASKCLUSTER_WORKER_ENV=Production (non case sensitive), the task fails if it can't create the user.
There was a problem hiding this comment.
I'd prefer that we used a configuration file exclusively, rather than a combination of env vars and a config file. This also has the advantage that we will have json schema for the config file, so it can be validated reasonably easily, and we'll detect problems on startup, rather than at task execution time.
|
Changes Unknown when pulling aa3f920 on walac:macosx into * on taskcluster:master*. |
|
@gregarndt may I merge this? (well, once I rebase the code) |
|
do eeet |
To run tasks concurrently in the same environment and make sure they don't mess up with each other, we run each of them with a different user, which also prevents tasks from doing fancy things to get secret information. For each new task, we create a new user on the fly, associate it to the staff group member and create a home directory. The task is triggered from user's home directory. After task is done, we remove the user as well as its home directory. In the case we fail to create a new user, we log the error but don't fail the task. This behavior is to let the tests pass even when running without capability to create users.
|
Changes Unknown when pulling d3c67e0 on walac:macosx into * on taskcluster:master*. |
Some language features may only be implemented in some Operating Systems, making builds fail on other OSes. We make the osxnative engine only builds on darwin kernel, where it is the only relevant OS for this engine.
|
Changes Unknown when pulling f1a722c on walac:macosx into * on taskcluster:master*. |
|
I rebased the branch, but for some reason travis doesn't understand that, going to merge it as fails are unrelated to this patch. |
Run tasks with their own user context.
To run tasks concurrently in the same environment and make sure they don't
mess up with each other, we run each of them with a different user, which
also prevents tasks from doing fancy things to get secret information.
For each new task, we create a new user on the fly, associate it to the
staff group member and create a home directory. The task is triggered
from user's home directory. After task is done, we remove the user as
well as its home directory.
In the case we fail to create a new user, we log the error but don't
fail the task. This behavior is to let the tests pass even when
running without capability to create users.