You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Benjamin Bannier (JIRA)" <ji...@apache.org> on 2017/01/05 08:44:58 UTC

[jira] [Updated] (MESOS-6856) Add test tooling to allow writing more tests changing user

     [ https://issues.apache.org/jira/browse/MESOS-6856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benjamin Bannier updated MESOS-6856:
------------------------------------
    Description: 
We currently largely avoid writing tests which execute processes as other users since in some setups such tests might not succeed. As noted in MESOS-6823,

{quote}
# if one runs {{make check}} as some user such as {{root}}, the default umask on the system might lead to creation of needed executables  which cannot be executed by other users like e.g., {{nobody}}
# depending on user choices required binaries might be created in paths not visible to some users such as {{nobody}} (think build directory somewhere under {{/home/me}} or like here {{/root}}). Note that regardless on what we do with permissions on e.g., Mesos build-controlled paths, the restrictive permissions might be set on parent directories we (as Mesos build setup) wouldn't want to touch directly.
{quote}

In isolated cases we implement explicit workarounds, see e.g., the [{{LinuxCapabilitiesTest}}|https://github.com/apache/mesos/blob/f89f28724f5837ff414dc6cc84e1afb63f3306e5/src/tests/containerizer/linux_capabilities_isolator_tests.cpp#L287-L291] for an example.

Since it is hard to ensure that both (1) and (2) are fully addressed by the Mesos build (possible for (1), but potentially impossible for (2)), a possible angle to allow us to write more tests which change the user (needed e.g., for tests of code paths with {{ContainerLaunchInfo.user}} set) might be
to implement a test filter disabling tests if permission problems are detected.

I believe we wouldn't need to restrict possible solutions to {{ROOT}} tests.

  was:
We currently largely avoid writing tests which execute processes as other users since in some setups such tests might not succeed. As noted in MESOS-6823,

{quote}
# if one runs {{make check}} as some user such as {{root}}, the default umask on the system might lead to creation of needed executables  which cannot be executed by other users like e.g., {{nobody}}
# depending on user choices required binaries might be created in paths not visible to some users such as {{nobody}} (think build directory somewhere under {{/home/me}} or like here {{/root}}). Note that regardless on what we do with permissions on e.g., Mesos build-controlled paths, the restrictive permissions might be set on parent directories we (as Mesos build setup) wouldn't want to touch directly.
{quote}

In isolated cases we implement explicit workarounds, see e.g., the [{{LinuxCapabilitiesTest}}|https://github.com/apache/mesos/blob/f89f28724f5837ff414dc6cc84e1afb63f3306e5/src/tests/containerizer/linux_capabilities_isolator_tests.cpp#L287-L291] for an example.

Since it is hard to ensure that both (1) and (2) are fully addressed by the Mesos build (possible for (1), but potentially impossible for (2)), a possible angle to allow us to write more tests which change the user (needed e.g., for tests of code paths with {{ContainerLaunchInfo.user}} set) might be
to implement a test filter disabling tests if permission problems are detected.

I believe we wouldn't need to restrict possible solutions to {{ROOT}}} tests.


> Add test tooling to allow writing more tests changing user
> ----------------------------------------------------------
>
>                 Key: MESOS-6856
>                 URL: https://issues.apache.org/jira/browse/MESOS-6856
>             Project: Mesos
>          Issue Type: Improvement
>          Components: test
>            Reporter: Benjamin Bannier
>              Labels: newbie
>
> We currently largely avoid writing tests which execute processes as other users since in some setups such tests might not succeed. As noted in MESOS-6823,
> {quote}
> # if one runs {{make check}} as some user such as {{root}}, the default umask on the system might lead to creation of needed executables  which cannot be executed by other users like e.g., {{nobody}}
> # depending on user choices required binaries might be created in paths not visible to some users such as {{nobody}} (think build directory somewhere under {{/home/me}} or like here {{/root}}). Note that regardless on what we do with permissions on e.g., Mesos build-controlled paths, the restrictive permissions might be set on parent directories we (as Mesos build setup) wouldn't want to touch directly.
> {quote}
> In isolated cases we implement explicit workarounds, see e.g., the [{{LinuxCapabilitiesTest}}|https://github.com/apache/mesos/blob/f89f28724f5837ff414dc6cc84e1afb63f3306e5/src/tests/containerizer/linux_capabilities_isolator_tests.cpp#L287-L291] for an example.
> Since it is hard to ensure that both (1) and (2) are fully addressed by the Mesos build (possible for (1), but potentially impossible for (2)), a possible angle to allow us to write more tests which change the user (needed e.g., for tests of code paths with {{ContainerLaunchInfo.user}} set) might be
> to implement a test filter disabling tests if permission problems are detected.
> I believe we wouldn't need to restrict possible solutions to {{ROOT}} tests.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)