4

During the development of a script, some bugs remain "latent" until the script is run by a different user. (For example, the script may access a file that only the person developing the script has access to.)

Is there a way to run the script with the same privileges that the "intended user" of the script would minimally have?

(Please note the question's wording. I specifically avoided writing "user with minimal privileges", because in some cases the "intended user" may be expected to more than "minimal privileges". The case that most readily comes to mind is the one where the "intended user" is expected to belong to a specific group.)

Of course, one simple solution would be to create a dummy user with the desired privileges, but this solution requires having user-creation privileges, which is not always the case. I'm interested in solutions that could be used even when creating a dummy user is not an option.

Improve this question
  • 3
    I can only think of two ways; one being the creation of the dummy user, two being executing the script with a special user account using sudo. Both require root(-like) access, and as such don't seem to be feasible for your situation. If gaining the required privileges is a problem I'd suggest asking for a VM in which you have full access and develop as root, testing your script with su - user -c "/path/to/script <params>" – tink Mar 19 '13 at 19:30
  • 1
    This seems to be a question about test environment best practices, rather than accomplishing a specific task on *nix. Perhaps SO would be a better place to ask? Also, a specific example script would be nice to see too. – depquid Mar 19 '13 at 19:30
0

In those days of cheap virtual machines, not being able to create test users isn't usual.

You can run the program under a minimal environment: a sensible default PATH (usually /usr/local/bin:/usr/bin:/bin), HOME, and whatever the program needs. Set HOME to a subdirectory of your home directory or somewhere else altogether (e.g. under /tmp), populated with only the files that the program expects to find. This is already a first test against accidental environment dependencies. You may want to restrict the path to a /tmp/for-testing/bin containing only a few programs that are supposed to be enough, to test against accidental dependencies on third-party software. Still, a test in a default installation of some distribution would be more conclusive.

If the program needs access to some local files, you may nonetheless be able to test against unexpected dependencies on other files by playing with fakechroot. Create a directory containing everything the system may need (down to the linker and standard library), plus the program and its data files, and fakechroot into it (a real chroot would need root permissions).

Improve this answer
-1

My understanding of this question is that you want to run the script as a particular user so it isn't develop being specific to the dev user's account. This is pretty much what sudo is intended to do. Just create a sudo user rule like thus:

devUser    ALL=(targetUser)    NOPASSWD: /path/to/script

and then "devUser" can run the script like thus:

$ sudo -u targetUser /path/to/script

I'd prefer sudo over "su" since NOPASSWD would make development a little easier.

Improve this answer
  • It's highly unlikely that someone unable to create a dummy user would be able to edit the sudo config. – depquid Mar 19 '13 at 21:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.