CHE-3359 - Starting a workspace as an user #3376

snjeza · 2016-12-13T21:11:31Z

What does this PR do?

Fixes #3359

What issues does this PR fix or reference?

#3359

Signed-off-by: Snjezana Peco [email protected]

codenvy-ci · 2016-12-13T21:14:01Z

Can one of the admins verify this patch?

l0rd · 2016-12-13T22:33:04Z

...-docker-machine/src/main/java/org/eclipse/che/plugin/docker/machine/MachineProviderImpl.java

+    private void prepareContainer(String containerId, LineConsumer machineLogger) throws MachineException {
+        String prepareCmd = "CHE_USER=`id -un`;"
+                + "sudo chown -R ${CHE_USER}:docker /home/user;"
+                + "sudo ln -s /home/user `eval echo \"~${CHE_USER}\"`";


Why do you need to create this symbolic link?

l0rd · 2016-12-13T22:35:51Z

...-docker-machine/src/main/java/org/eclipse/che/plugin/docker/machine/MachineProviderImpl.java

@@ -340,7 +347,27 @@ public Instance startService(String namespace,
        }
    }

-    @Override
+    private void prepareContainer(String containerId, LineConsumer machineLogger) throws MachineException {


name prepareContainer doesn't say much about this method. What about changeWorkingDirOwner?

l0rd · 2016-12-13T22:37:25Z

...-docker-machine/src/main/java/org/eclipse/che/plugin/docker/machine/MachineProviderImpl.java

+            throw new MachineException(format("Error occurs while executing command %s in docker container %s: %s",
+                                              Arrays.toString(exec.getCommand()), containerId, e.getMessage()), e);
+        }
+	}


I think that last curly bracket is not correctly aligned

l0rd · 2016-12-13T22:48:59Z

@snjeza your PR looks ok to me. How have you tested your PR? Can you please tell me the command line you have used to start Che and the simple steps of your tests?

@garagatyi and @benoitf I think you should have a look too

snjeza · 2016-12-14T12:46:45Z

Why do you need to create this symbolic link?

Che supposes a workspace runs as the "user" user that has a specific home directory. The command sets the same environment for any user starting the workspace.

your PR looks ok to me. How have you tested your PR? Can you please tell me the command line you have used to start Che and the simple steps of your tests?

You start che as described in #3265

docker run -p 8080:8080 \
           --name che \
	   --rm \
	   -u `id -u test` \
           -v /var/run/docker.sock:/var/run/docker.sock \
           -e CHE_USER=test \
           -v /tmp/data:/data \
	   -v /etc/group:/etc/group:ro \
	   -v /etc/passwd:/etc/passwd:ro \
           eclipse/che-server:ver

create a workspace and call

docker exec <workspace_container_id> id

If you start a workspace as usually, you will get the user "user(1000)". When using the above command, you will get the "test" user and its ID. The test user must have the sudo NOPASSWD permission (must be a member of the sudo group).

garagatyi · 2016-12-19T11:56:58Z

@snjeza Can you elaborate on what this PR does and what for. It is not clear in most cases what PRs do, so we are welcoming in PRs body detailed explanation of all information needed for reviewers.

garagatyi · 2016-12-19T11:49:54Z

...n-docker-client/src/main/java/org/eclipse/che/plugin/docker/client/json/ContainerConfig.java

@@ -41,7 +42,7 @@
    // from docs for 1.15 API https://docs.docker.com/reference/api/docker_remote_api_v1.15/#create-a-container
    // An object mapping ports to an empty object in the form of: "ExposedPorts": { "<port>/<tcp|udp>: {}" }
    private Map<String, Map<String, String>> exposedPorts = new HashMap<>();
-    private String                           user         = "";
+    private String                           user         = System.getenv(CHE_USER_ID) == null ? "" : System.getenv(CHE_USER_ID);


This object is simple POJO. It should not include any logic for fields evaluation based on environment settings.

garagatyi · 2016-12-19T11:50:32Z

...-docker-machine/src/main/java/org/eclipse/che/plugin/docker/machine/MachineProviderImpl.java

@@ -294,6 +297,10 @@ public Instance startService(String namespace,

            docker.startContainer(StartContainerParams.create(container));

+            if (System.getenv("CHE_USER_ID") != null) {


PLease use injection to check env variables.

I'm not sure how to do that.

@snjeza https://github.com/eclipse/che/blob/e8840780afc9ba8ebeaa4af9730f5e749cda4ebc/plugins/plugin-java/che-plugin-java-ext-lang-server/src/main/java/org/eclipse/che/plugin/java/server/rest/WsAgentURLProvider.java#L45

garagatyi · 2016-12-19T11:51:23Z

...-docker-machine/src/main/java/org/eclipse/che/plugin/docker/machine/MachineProviderImpl.java

@@ -294,6 +297,10 @@ public Instance startService(String namespace,

            docker.startContainer(StartContainerParams.create(container));

+            if (System.getenv("CHE_USER_ID") != null) {
+                changeWorkingDirOwner(container, machineLogger);


It is not clear why we need that. PLease comment code or add javadocs to this method on why we do that

When che starts a workspace, it expects that there is the "user" user that has the /home/user directory as the home directory with a specific content.
You can check that by the following:

docker run -it codenvy/ubuntu_jdk8 id docker run -it codenvy/ubuntu_jdk8 ls -la /home/user

The changeWorkingDirOwner method sets the same environment for a user defined with CHE_USER which enables us to use the existing che images.

snjeza · 2016-12-19T20:44:16Z

@snjeza Can you elaborate on what this PR does and what for. It is not clear in most cases what PRs do, so we are welcoming in PRs body detailed explanation of all information needed for reviewers.

CHE-3264 implements the CHE_USER environment variable. However, only the che server is started as a user defined with CHE_USER.
Workspaces still start as the "user" user. This PR enables a workspace to start as a user defined with the CHE_USER environment variable.

By executing the following command, you can see which user started the che server or a workspace:

docker exec -it <server_container_id> id
docker exec -it <workspace_container_id> id

benoitf

FYI @snjeza master branch has been rewritten on docs import to discard images files so you'll have to rebase your branch to be in sync with latest master. I can help around this task if you need help

garagatyi · 2016-12-20T14:03:32Z

I don't understand why should we change user inside of workspace containers and change ownership of files. It is quiet risky operation to me that can raise a lot of issues with some specific software in containers.
Please provide more information on why we need that.

TylerJewell · 2016-12-20T14:09:44Z

The basic expectation is that a workspace is the ownership of the user, not of Che. And so if the end user or admin thinks of a workspace runtime as "their" property, then they want to have root-like behaviors. Their project may require a certain user identity or other override behaviors. So this would give an admin the ability to configure a workspace as a particular user.

garagatyi · 2016-12-21T11:23:52Z

...main/java/org/eclipse/che/plugin/docker/machine/local/LocalCheInfrastructureProvisioner.java

@@ -89,7 +94,26 @@ public void provision(Environment envConfig, CheServicesEnvironmentImpl internal
                   .add(SystemInfo.isWindows() ? pathEscaper.escapePath(projectFolderVolume)
                                               : projectFolderVolume);

+        if (System.getenv(CHE_USER_ID) != null) {


Please use dependency injection instead of getenv method. Take a look at my comment to learn more about that.

garagatyi · 2016-12-21T11:24:11Z

...-docker-machine/src/main/java/org/eclipse/che/plugin/docker/machine/MachineProviderImpl.java

@@ -541,6 +570,10 @@ private String createContainer(String workspaceId,
                     .getId();
    }

+    protected String getUser() {
+        return System.getenv("CHE_USER_ID") == null ? "" : System.getenv("CHE_USER_ID");


Please use dependency injection instead of getenv method. If named property starts from env. it is retrieved from environment variables by name that follows prefix env.. For example @Named("env.MY_VAR") String str injects value from env variable MY_VAR. Also it is better to do that in constructor.

garagatyi · 2016-12-21T11:26:07Z

...-docker-machine/src/main/java/org/eclipse/che/plugin/docker/machine/MachineProviderImpl.java

@@ -341,7 +348,28 @@ public Instance startService(String namespace,
        }
    }

-    @Override
+    // sets the home directory for a user defined with CHE_USER
+    private void changeWorkingDirOwner(String containerId, LineConsumer machineLogger) throws MachineException {


Please cover changed code with unit tests. See MachineProviderImplTest

garagatyi · 2016-12-22T10:13:08Z

...main/java/org/eclipse/che/plugin/docker/machine/local/LocalCheInfrastructureProvisioner.java

@@ -89,7 +94,26 @@ public void provision(Environment envConfig, CheServicesEnvironmentImpl internal
                   .add(SystemInfo.isWindows() ? pathEscaper.escapePath(projectFolderVolume)
                                               : projectFolderVolume);

+        if (System.getenv(CHE_USER_ID) != null) {
+            addVolume(internalEnv, devMachineName, ETC_PASSWD_VOLUME);


Please add unit tests to cover changed code. Unfortunately there are no tests yet for this class. But you can cover only your code if you will.

garagatyi · 2016-12-22T10:16:53Z

...-docker-machine/src/main/java/org/eclipse/che/plugin/docker/machine/MachineProviderImpl.java

@@ -528,6 +556,7 @@ private String createContainer(String workspaceId,
              .withEntrypoint(toArrayIfNotNull(service.getEntrypoint()))
              .withLabels(service.getLabels())
              .withNetworkingConfig(networkingConfig)
+              .withUser(getUser())


Will container start if there is no such user in container?

Probably with mounting of /etc/passwd and /etc/group user kinda already exists in container. But there is possibility of permissions problems.

@garagatyi user will be the same that is running in che-server container. The same env variable CHE_USER_ID is used by both workspace and che-server.

By the way I think the purpose of this PR is to solve permissions problems. Let's say that I'm logged in my Linux box using user mario. When starting a Che workspace I would expect it to run as user mario too. With permission to open files that I can read and only those. This user does not exist in the original recipe docker image but mounting the /etc/passwd will do the trick.

Yes, I got it. Thanks for additional explanation.

garagatyi · 2016-12-22T10:18:25Z

...-docker-machine/src/main/java/org/eclipse/che/plugin/docker/machine/MachineProviderImpl.java

+    private void changeWorkingDirOwner(String containerId, LineConsumer machineLogger) throws MachineException {
+        String prepareCmd = "CHE_USER=`id -un`;"
+                + "sudo chown -R ${CHE_USER}:docker /home/user;"
+                + "sudo ln -s /home/user `eval echo \"~${CHE_USER}\"`";


Mario asked that and I haven't found answer. Why do you need to create this symbolic link?

garagatyi · 2016-12-22T10:25:47Z

...main/java/org/eclipse/che/plugin/docker/machine/local/LocalCheInfrastructureProvisioner.java

+            path = format("%s:%s:ro", volume, volume);
+        }
+        internalEnv.getServices()
+                .get(devMachineName)


Why mapping of these files are needed for dev machines only and not all the machines?

garagatyi · 2016-12-22T10:28:50Z

...-docker-machine/src/main/java/org/eclipse/che/plugin/docker/machine/MachineProviderImpl.java

@@ -294,6 +297,10 @@ public Instance startService(String namespace,

            docker.startContainer(StartContainerParams.create(container));

+            if (!Strings.isNullOrEmpty(getUser())) {
+                changeWorkingDirOwner(container, machineLogger);


Is it OK that previous user in container is already running main process of container?

Sorry I misunderstood it a bit. In that case main process will run under new user but files on container's FS will be under old user. It can raise problem with that container. WDYT?

garagatyi · 2016-12-22T10:29:44Z

...-docker-machine/src/main/java/org/eclipse/che/plugin/docker/machine/MachineProviderImpl.java

+    // sets the home directory for a user defined with CHE_USER
+    private void changeWorkingDirOwner(String containerId, LineConsumer machineLogger) throws MachineException {
+        String prepareCmd = "CHE_USER=`id -un`;"
+                + "sudo chown -R ${CHE_USER}:docker /home/user;"


Why user home dir here and in link uses hardcoded path /home/user? User in container can have another name. And if it is root it can be in /root instead.

And user may not have home directory at all. And main process of container may have some permissions problems because of some hardcoded permissions on FS in container but not in home folder.

could we get home directory ?
why are we not using $HOME or getent passwd with user

@benoitf do you agree that $HOME does not correspond to /home/user here right? By the way /home/user/

TylerJewell · 2017-01-05T17:01:43Z

Alex - I generally agree with that basic philosophy. I actually don't know how we haven't been getting user complaints on this limitation in higher volume.

snjeza · 2017-01-09T04:33:13Z

I have updated the patch.

l0rd · 2017-01-09T10:48:27Z

@snjeza I'm sorry but I'm getting lost here 😄

Could you remember me what you have you changed since the last commit? Looking at current PR I can't remember the difference of this last update with the previous one.

And there is a question about the commands executed in the container (chown and ln -s) that hasn't been answered.

I think we are really close to merge this PR but we need these details from you.

pr has been rebased

garagatyi · 2017-01-09T11:50:02Z

...-docker-machine/src/main/java/org/eclipse/che/plugin/docker/machine/MachineProviderImpl.java

+            return;
+        }
+        try {
+            if (exec != null) {


This method is not covered by tests, can you cover it?

garagatyi · 2017-01-09T11:56:08Z

...-docker-machine/src/main/java/org/eclipse/che/plugin/docker/machine/MachineProviderImpl.java

+    // sets the home directory for a user defined with CHE_USER
+    private void changeWorkingDirOwner(String containerId, LineConsumer machineLogger) throws MachineException {
+        String prepareCmd = "CHE_USER=`id -un`;"
+                + "sudo chown -R ${CHE_USER}:docker /home/user;"


What if user is root in a container? His home folder will be /root instead of /home/user. Or even if user has different username - not the "user".

snjeza · 2017-01-09T18:01:26Z

@l0rd

Could you remember me what you have you changed since the last commit? Looking at current PR I can't remember the difference of this last update with the previous one.

Regarding @garagatyi requests, I have added the following:

a dependency injection instead of the getenv method
mapping /etc/passwd, /etc/group for all machines, not for a dev machine only
two tests

And there is a question about the commands executed in the container (chown and ln -s) that hasn't been answered.

I have already answered it.

Why do you need to create this symbolic link?

Che supposes a workspace runs as the "user" user that has a specific home directory. The command sets the same environment for any user starting the workspace.

The home directory contains some required files (maven, tomcat, ...). Che won't start a workspace if those files/directories aren't present.

What if user is root in a container? His home folder will be /root instead of /home/user. Or even if user has different username - not the "user".

The command won't do anything. We don't know what to do in this case because we don't know what user is a default user. Do you know an image I could test?

This method is not covered by tests, can you cover it?

I have tried to do it, but the che mockup docker container returns null when calling "docker.createExec". I don't know how to test this method.

@garagatyi

How to fix the issue with @nAmed("env.MYVAR") when MYVAR isn't set? Che throws an exception in this case.

garagatyi · 2017-01-10T08:54:46Z

The command won't do anything. We don't know what to do in this case because we don't know what user is a default user. Do you know an image I could test?

I suppose that if current user is root and user "user" exists in s container this command will do unneeded chown.
I think you can try to use official ubuntu image to check situation when user is root.
And probably in bitnami stacks user is named in a different way, but I'm not sure.

I have tried to do it, but the che mockup docker container returns null when calling "docker.createExec". I don't know how to test this method.

Here is an example how to use mocks to stub container creation. You can do pretty the same for exec. The difference is that you can do it in you specific test instead of setup method because this stubbing is not needed by other tests.
https://github.com/eclipse/che/blob/master/plugins/plugin-docker/che-plugin-docker-machine/src/test/java/org/eclipse/che/plugin/docker/machine/MachineProviderImplTest.java#L136-L136
If it is unclear on how to do that, please, notify me and I'll try to help you on that.

How to fix the issue with @nAmed("env.MYVAR") when MYVAR isn't set? Che throws an exception in this case.

Yes, we don't have such behavior for now. What can I suggest instead is to create property. Then it will be possible to inject it, to have default value as null and to override it with environment variable.
If you are not sure how to do that I can explain in details how this technic works in Che.

l0rd · 2017-01-10T10:51:58Z

| The home directory contains some required files (maven, tomcat, ...). Che won't start a workspace if those files/directories aren't present.

This means that the workspaces Docker images have been built assuming that they will be run by user user. Adding a symbolic link + chown is just a workaround. We should address the root cause in the Docker images instead. Once we modify the Docker images we can remove the workaround but I think we can do that work in a distinct PR. We should open an issue to track that. @snjeza and @garagatyi what do you think?

garagatyi · 2017-01-10T13:37:05Z

@l0rd Sorry I don't understand what do you mean. If you want to run containers by user "myuser" there is no possibility to fix root issue that it was not considered by author of docker image.
Can you elaborate on which another issue we can create and what can we fix to remove that workaround

l0rd · 2017-01-10T13:56:16Z

@garagatyi Let's take Java default stack. Tomcat and maven are installed in /home/user folder:

RUN mkdir /home/user/tomcat8 /home/user/apache-maven-$MAVEN_VERSION

This should be changed. Along with everything is related to a specific user. Docker images should be built to be a run as any user. For example tomcat and maven could be installed in /che/apps/ that is not related to a particular user.

garagatyi · 2017-01-10T14:03:27Z

I don't see the reason why stack author have to predict that someone would want to change user in container he designed. Also users can create workspaces from custom recipes instead of stacks. In that case we can't rely on what user exists in container and how software is configured in that container.

sunix · 2017-02-27T09:08:51Z

hi @snjeza, could you rebase/fix conflicts with master ?

snjeza · 2017-02-27T18:08:49Z

@sunix I have rebased the patch.

sunix · 2017-03-01T09:34:47Z

Thanks @snjeza will review and test this week

snjeza · 2017-03-07T18:18:08Z

@sunix
You can test this PR in the following way:

# build che with the PR
$ git fetch origin pull/3376/head:che-3359
$ git checkout che-3359
$ mvn clean install
$ cd dockerfiles/che
$ ./build.sh
# select a user; the user must have the sudo nopasswd privilege and must be a member of the docker group
# I have created the "test" user with userid=1001; docker gid=1001
$ grep test /etc/passwd
test:x:1001:1002::/home/test:/bin/bash
$ grep docker /etc/group
docker:x:1001:test,snjeza
$ sudo chown -R 1001:1001 /tmp/data/
# run che as a user; 
$ docker run -it \
 --user 1001:1001 --rm \
 -v /var/run/docker.sock:/var/run/docker.sock \
 -v /tmp/data:/data \
 -v /etc/passwd:/etc/passwd\
 -v /etc/group:/etc/group \
 eclipse/che:nightly start --fast
 
# The --fast option skips pulling an image when it exists, i.e., docker will use a local eclipse/che-server:nightly image
# open the che dashborad and create a workspace
# check that the che server and the workspace start as a user with id=1001
$ docker exec -it che id
uid=1001(test) gid=1001(docker)
$ docker exec -it <workspace_container_id> id
uid=1001(test) gid=1001(docker) groups=1001(docker)

You have to use Linux to test this feature.

TylerJewell · 2017-03-07T18:27:47Z

@snjeza - you should not have to use CHE_USER. What happens if you drop the --fast parameter for bootup?

snjeza · 2017-03-07T18:52:07Z

@TylerJewell che starts as the root user

$ docker run -it \
  --user 1001:1001 --rm \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /tmp/data:/data \
  -v /etc/passwd:/etc/passwd \
  -v /etc/group:/etc/group \
  eclipse/che:nightly start

INFO: (che cli): nightly - using docker 17.03.0-ce / native
INFO: (che download): Pulling image eclipse/che:nightly

nightly: Pulling from eclipse/che
709515475419: Already exists 
e50c49019c4a: Pull complete 
56c2701a8f06: Pull complete 
9bcb79f184df: Pull complete 
9241a5c9b8a9: Pull complete 
7c0086b14556: Pull complete 
188b1f780e80: Pull complete 
1765d0e493f3: Pull complete 
Digest: sha256:17d4458e8219a9ca3cd3d141fde2ba1feb91be2f27a8d1232a3946714e347003
Status: Downloaded newer image for eclipse/che:nightly

WARN: Pulled new 'nightly' image - please rerun CLI

$ docker run -it \
  --user 1001:1001 --rm \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /tmp/data:/data \
  -v /etc/passwd:/etc/passwd \
  -v /etc/group:/etc/group \
  eclipse/che:nightly start

INFO: (che cli): nightly - using docker 17.03.0-ce / native
INFO: (che download): Pulling image eclipse/che:nightly

nightly: Pulling from eclipse/che
Digest: sha256:17d4458e8219a9ca3cd3d141fde2ba1feb91be2f27a8d1232a3946714e347003
Status: Image is up to date for eclipse/che:nightly

WARN: (che init): 'nightly' installations cannot be upgraded to non-nightly versions
INFO: (che init): Installing configuration and bootstrap variables:
INFO: (che init):   CHE_HOST=172.20.0.1
INFO: (che init):   CHE_VERSION=nightly
INFO: (che init):   CHE_CONFIG=/tmp/data
INFO: (che init):   CHE_INSTANCE=/tmp/data/instance
INFO: (che config): Generating che configuration...
INFO: (che config): Customizing docker-compose for running in a container
INFO: (che start): Preflight checks
         mem (1.5 GiB):           [OK]
         disk (100 MB):           [OK]
         port 8080 (http):        [AVAILABLE]
         conn (browser => ws):    [OK]
         conn (server => ws):     [OK]

INFO: (che start): Starting containers...
INFO: (che start): Services booting...
INFO: (che start): Server logs at "docker logs -f che"
INFO: (che start): Booted and reachable
INFO: (che start): Ver: nightly
INFO: (che start): Use: http://172.20.0.1:8080
INFO: (che start): API: http://172.20.0.1:8080/swagger

$ docker exec -it che id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)

TylerJewell · 2017-03-07T23:07:27Z

oh my god - there was a refactoring of the CLI and the check_user method was not included. head slap. This method does one thing, and that is to extract --user value and assign it to CHE_USER.

TylerJewell · 2017-03-07T23:14:42Z

@snjeza - here is the PR that fixes that little mistake. The function was always in the CLI but in the refactoring it was no longer being invoked. #4350

Signed-off-by: Snjezana Peco <[email protected]>

codenvy-ci · 2017-07-10T14:07:05Z

Can one of the admins verify this patch?

codenvy-ci · 2017-10-05T08:26:17Z

Can one of the admins verify this patch?

garagatyi · 2017-10-05T14:20:42Z

@snjeza @l0rd is this PR still actual?

l0rd · 2017-10-05T18:35:15Z

@garagatyi I think that this PR is useful and we can have someone working on it to rebase it. But it would be better to rebase it on top of the SPI branch, not master. What do you think?

garagatyi · 2017-10-06T09:00:22Z

@l0rd On which infra do you want to support it?

l0rd · 2017-10-11T09:52:07Z

@garagatyi in OpenShift this is automatically handled by the infra (by default user id is choosen arbitrarly) so I guess that Docker infra is missing that at the moment.

garagatyi · 2017-10-11T11:17:20Z

I'm not sure what for it is needed in case of Docker infrastructure. And the solution is tricky which may lead to unexpected behavior of software in containers

codenvy-ci · 2018-01-09T14:14:33Z

Can one of the admins verify this patch?

skabashnyuk · 2018-07-05T11:17:07Z

closing. There is no interest in this pr.

l0rd reviewed Dec 13, 2016

View reviewed changes

l0rd requested review from benoitf and garagatyi December 13, 2016 22:49

snjeza force-pushed the che-3359 branch from 8d3293b to 1036471 Compare December 14, 2016 12:51

garagatyi reviewed Dec 19, 2016

View reviewed changes

snjeza force-pushed the che-3359 branch from 1036471 to c4e7e68 Compare December 20, 2016 01:07

benoitf force-pushed the master branch 2 times, most recently from f0ee59a to aba9a87 Compare December 20, 2016 09:31

benoitf previously requested changes Dec 20, 2016

View reviewed changes

snjeza force-pushed the che-3359 branch from c4e7e68 to a47be30 Compare December 20, 2016 18:38

garagatyi reviewed Dec 22, 2016

View reviewed changes

snjeza force-pushed the che-3359 branch from a47be30 to 34c04a6 Compare January 9, 2017 04:32

garagatyi reviewed Jan 9, 2017

View reviewed changes

l0rd requested a review from sunix February 24, 2017 16:36

snjeza force-pushed the che-3359 branch from 99b7571 to 935c180 Compare February 27, 2017 18:06

snjeza force-pushed the che-3359 branch 2 times, most recently from 0057419 to f698203 Compare March 6, 2017 18:45

TylerJewell mentioned this pull request Mar 7, 2017

[cli] Add back in check for --user on command line #4350

Merged

snjeza added 4 commits March 8, 2017 21:30

CHE-3359 - Starting a workspace as an user

8a2023f

Signed-off-by: Snjezana Peco <[email protected]>

fixup! CHE-3359 - Starting a workspace as an user

c610913

fixup! CHE-3359 - Starting a workspace as an user

36d0b11

fixup! CHE-3359 - Starting a workspace as an user

801b307

Signed-off-by: Snjezana Peco <[email protected]>

snjeza force-pushed the che-3359 branch from f698203 to 801b307 Compare March 8, 2017 20:31

benoitf added status/code-review This issue has a pull request posted for it and is awaiting code review completion by the community. kind/enhancement A feature request - must adhere to the feature request template. labels Oct 5, 2017

skabashnyuk closed this Jul 5, 2018

		@@ -294,6 +297,10 @@ public Instance startService(String namespace,

		docker.startContainer(StartContainerParams.create(container));

		if (System.getenv("CHE_USER_ID") != null) {

CHE-3359 - Starting a workspace as an user #3376

CHE-3359 - Starting a workspace as an user #3376

Conversation

snjeza commented Dec 13, 2016

What does this PR do?

What issues does this PR fix or reference?

codenvy-ci commented Dec 13, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

l0rd commented Dec 13, 2016

snjeza commented Dec 14, 2016

garagatyi commented Dec 19, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

snjeza Dec 19, 2016 • edited Loading

Choose a reason for hiding this comment

snjeza commented Dec 19, 2016

benoitf left a comment

Choose a reason for hiding this comment

garagatyi commented Dec 20, 2016

TylerJewell commented Dec 20, 2016

garagatyi Dec 21, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TylerJewell commented Jan 5, 2017

snjeza commented Jan 9, 2017

l0rd commented Jan 9, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

snjeza commented Jan 9, 2017 • edited Loading

garagatyi commented Jan 10, 2017

l0rd commented Jan 10, 2017

garagatyi commented Jan 10, 2017

l0rd commented Jan 10, 2017

garagatyi commented Jan 10, 2017

sunix commented Feb 27, 2017

snjeza commented Feb 27, 2017

sunix commented Mar 1, 2017

snjeza commented Mar 7, 2017 • edited Loading

TylerJewell commented Mar 7, 2017

snjeza commented Mar 7, 2017

TylerJewell commented Mar 7, 2017

TylerJewell commented Mar 7, 2017

codenvy-ci commented Jul 10, 2017

codenvy-ci commented Oct 5, 2017

garagatyi commented Oct 5, 2017

l0rd commented Oct 5, 2017

garagatyi commented Oct 6, 2017

l0rd commented Oct 11, 2017

garagatyi commented Oct 11, 2017

codenvy-ci commented Jan 9, 2018

skabashnyuk commented Jul 5, 2018

snjeza Dec 19, 2016 •

edited

Loading

garagatyi Dec 21, 2016 •

edited

Loading

snjeza commented Jan 9, 2017 •

edited

Loading

snjeza commented Mar 7, 2017 •

edited

Loading