Should testers have root access or not, on personal VM, given that developers do?

Question

In a development environment where developers are freely given root / admin access to their personal development VM's is there a need to prevent integration testers from having root / admin access in their personal testing VM's?

The environment will use continuous integration and continuous deployment and aims to follow DevOps.

Naturally anyone who has root / admin access shouldn't log in as root / admin all the time. This question is about who is allowed access to both accounts when doing their work.

Developers have root / admin access so they can configure their personal vm's to meet their needs. Should a tester who is creating tests be able to do the same?

This question is not about whether a test should be run with root privileges. It's about whether a person who writes tests has to ask someone else to configure the personal VM they use to create the tests.

By testers personal VM I'm referring to the VM they use to create automated integration tests. The ones a developer should be able to run on their own personal VM before checking in code.

Answer 1

The situation looks pretty simple to me: people need the tools to do their job correctly. If they need root access, they should be given root access and they should be trusted (and trained, if necessary) to use it responsibly.

Similarly, if they don't need root access then there is no reason to give it to them.

Answer 2

While root/admin access to the machine may be useful for setting up the environment, tests should be run in a way the "normal" user of the product does. In most cases, this will mean that a "normal" user account should be used (that does not exclude an additional root account for setup/configuration). If the system under test has its own user rights management, tests with low user rights are extremely important. In my experience, the worst and hardest to find bugs involve problems with user rights.

From the point of view of testing, the access rights typically granted to developers are irrelevant. Granting root/admin rights to testers is only relevant if they have to perform tasks requiring such elevated rights (which might be the case for setup and configuration). And they should be aware that when tempering with the machine configuration, this may have influences on their test results and may yield reproducibility issues. Hence, not granting elevated rights should normally be the way to go.

Answer 3

DevOps integrates the full software lifecycle, including the system administration required for the operations.

As operations may include deployment and system configuration activities (including activities that require root access), some integration testers may need root access (including to test servers) in order to test the quality attributes intended for operations (e.g. operability).

Of course a system has not only operations, but also end-users. Some integration testers must therefore test that end user features work as expected (i.e. without root access: some times, things do not work as well without root access as they should, and these issues must be caught during the tests).

So in short: nothing speaks against root access for some integration testers, but something advocates that at least some integration tester have only end user access (i.e: no root access, neither on their vm nor to the server)

N.B: the fact that developers have root access or not is IMO irrelevant for the answer

Answer 4

I would say testers definitely need root access, more even then developers.

If you want it or not, your program is going to be run in an elevated environment. Users are just like that.

The possibilities for your software to break things in spectacular ways are much greater in an elevated then a restricted environment.

So yes, testers need root to test whether the application doesn't do naughty things while running as root.

In the end: you must test in both a restricted environment and one without restrictions.

Answer 5

If the majority of customers runs the software not as a root user, then the tester should not run it as a root user. There may be bugs that make your software work only as root, and you want to find that before you ship to customers.

If you suspect that some customers might run as root, you might have one machine where you run the software as root - in case the software does something stupid that is prevented by lack of privileges, but causes damage as root. On the other hand, people who run as root without a very good reason have no excuse.