[VAL-50] Investigate Running LTP tests for the OS Layer as a Non-Root user Created: 18/Sep/19  Updated: 09/Oct/19  Resolved: 09/Oct/19

Status: Done
Project: Validation
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: High
Reporter: Deepak Kataria Assignee: Ioakeim Samaras
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

LTP tests need root access to run; options are either sudo or create a group with privileges as opposed to using root password.

We need to investigate if LTP can be run without root access.



 Comments   
Comment by Ioakeim Samaras [ 08/Oct/19 ]

There are three options:

1) Give CRUD permissions to the testing user on /opt/ltp directory. This can be achieved by enabling permissions on 'others'. Also, the bash shell must be supplied with the appropriate capabilities by using the 'setcap' command in order to execute the 'runltp' script. However, this option is complicated and requires many modifications on the tested host environment. Also, it is very dangerous to give full capabilities to bash shell.

2) Use the 'chroot' command in order to create a mock root directory where the testing user can perform any action. However, this option is complicated and requires many modifications on the tested host environment.

3) Enable the testing user to run only the '/opt/ltp/runltp' script as a sudoer with no password. This can be achieved by adding the following line in the '/etc/sudoers' file:

testing_user ALL= NOPASSWD: /opt/ltp/runltp

Then, the testing user can execute the command 'sudo /opt/ltp/runltp'. No password is needed.

 

As far as the execution of LTP tests in the CoreOS is concerned, this is not feasible. CoreOS is designed to be bare-bones and thus contain just enough functionality to provide a clustering infrastructure, and nothing more. There's no package manager and so the installation of LTP prerequisites is not feasible. 

 

 

Generated at Sat Feb 10 06:06:55 UTC 2024 using Jira 9.4.5#940005-sha1:e3094934eac4fd8653cf39da58f39364fb9cc7c1.