BASH help running a script as another user

[oshunluvr]

I'm working on a system where no one (except me) has sudo root access. I'm running an action from a menu that edits a file using a bash script along with some input form the user. The file to be edited is owned by another user and my regular users know that password. I want to avoid changing file and directory ownership or adding anything to sudoers.

Here, let say it this way to make it clearer:

User BOB has limited system rights, but BOB knows TEDs password.
User TED has more system rights than BOB and owns a bunch of data files that BOB can read, but not edit.
They have the same primary group.

To edit the file SCRIPT, you must be TED because both the file and the directory it's in belong to TED.

I have written a bash script to edit SCRIPT but it has to be run as TED.

I have been trying for days to figure out a way to switch BOB to TED when the script is launched, but have failed. I settled on two scripts, the first one calls the other. It looks like:

#!/bin/bash
printf "Enter TEDs "
su -c "/scripts/SCRIPT" TED

This is called inside xterm so the output looks like:

Enter TEDs Password:

Then the second scripts launches and works fine.. When I try to put this su command inside the second script, it opens a second terminal window and fails.

Having two scripts isn't the end of the world, I just wondered if there was a better way to do it.

[Snowhog]

Why sudo -c and not sudo -i ?

[oshunluvr]

No sudo at all.

su

[jlittle]

IMO groups, and group permissions, exist to handle these situations. Users can be in many groups.

Invent a group that has a name that explains its purpose, add TED and BOB to that group, set the group of the SCRIPT, and enable group write permission. No passwords required. Depending on the editor used, some thought might be needed about backup and temporary files the editor uses; but you'll have to consider that anyway.

[oshunluvr]

IMO groups, and group permissions, exist to handle these situations. Users can be in many groups.

Invent a group that has a name that explains its purpose, add TED and BOB to that group, set the group of the SCRIPT, and enable group write permission. No passwords required. Depending on the editor used, some thought might be needed about backup and temporary files the editor uses; but you'll have to consider that anyway.

They are in the same group, in fact the same primary group. The problem is mostly I'm trying to avoid wholesale changes to permissions or activating sudo. The users have menu driven access but we don't want obvious and easy access to stuff they're not to touch. My set up seems to work, just seems messy.

[Snowhog]

To edit the file SCRIPT, you must be TED because both the file and the directory it's in belong to TED.

Why not just create a special 'shared folder' that BOB and TED have rw access to, and put the script there? Wouldn't that be simpler and cleaner?

[oshunluvr]

Why not just create a special 'shared folder' that BOB and TED have rw access to, and put the script there? Wouldn't that be simpler and cleaner?

Yes, but that would require re-configuring 90+ computer systems spread out over the entire country. A lot of work for what amounts to a trivial system change. What I considered was changing the permissions of the file and folder in question, but I'm concerned about unintended consequences and the lessening of security resulting in something I get blamed for and have to fix.

The way this will be implemented nation wide is a bi-annual software insertion via an executable package that we do with field service techs, but they're very low level (skill wise) and work for me so I know they won't cause issues. It's the people that don't work for me (the users) having added access that concern me.

The action that I'm adding to the menu is a simple function toggle to turn a feature on or off, what we call "an INI change." Currently, if a user wants it changed, I have to walk them through - over the phone - gaining root access and trusting them to do the edit correctly and not using the root password to go in and muck about with other things they not supposed to be touching. By adding it as a menu function, I remove the need to be involved with the configuration change when it's needed and I reduce the chances of intentional or accidental shenanigans.

The menu that launches the script is for BOB level access. The script that does the edit - a simple sed replace-in-place one-liner - needs to have TED level access or sed fails because it creates a temp file in the target directly. I tried using a temp redirect to store the edits, which worked but I still can't insert the edits into the current file.

Oh well, my two script solution works so I'll send it out that way. I really just wanted to know if I missed some bash magic that I wasn't aware of.

Actually, one nice thing about it, since it's basically shell actions that run in a terminal window, the fact that it's two scripts is totally transparent to the user. So in a way, it's probably less obvious what's happening to the casual user.

[Snowhog]

Yes, but that would require re-configuring 90+ computer systems spread out over the entire country.

Ah. I thought this was a simple 'two person' issue on your own home network.

Have you seen this: https://stackoverflow.com/questions/...script/8352939