Identical user 1

[maxthedork]

Greetings.

I'd like to create a new user that is based on the rights/permissions of another existing user. Is there a way to do this in Linux or no? In Windows, I select a user and click "Copy User" to do this. But I don't see any way of duplicating users with similar rights and permissions in Linux.

Thanks in advance.

 

[RhythmAce]

I don't think there is a way to do that in linux. Ever wonder why Windows has sommany security problems? However, linux provides a way to let users switch to another user (kinda) with the su command. To do this you must have the other user's password. You can read more about it by typing "man su" from the command shell.

 

[maxthedork]

Thanks for your prompt reply! I was afraid of that. And yes, I understand the issues with Windows security. The problem I'm facing is this: We have an application suite that is rather extensive, and the user that has rights to run everything is an internal user. The user has been set up on each of four servers, and the application was installed using that user's credentials. I'll call the user "installguy". So installguy can do everything necessary to run the application. However, we have a remote support contract and we don't necessarily want the remote team logging in with installguy, so we created a new user, let's call him "remoteguy". I added remoteguy to the group installguy and made sure the installguy group had rights to various logfiles and whatnot. Also copied installguy's .bash_profile to remoteguy's home directory. Now, I had to do this on all four servers. I was just wondering if there was an easier way. Especially since there's still some stuff I need to track down because it's not working for remoteguy. But I'm guessing from your response that my work has only just begun (-;

Oh, and the main reason we want to force the remote support people to use remoteguy is so we can track what they do, especially since they will have access to the system when we're not around.

Thanks again!

 

[elgrandeperro]

2 things.

With "sudo" you could restrict a user to run certain commands as another user, and it logs.

Another way to do it is to have individual accounts and use some type of RBAC solution. I've done this in Solaris but I am sure it must be available on Linux.

 

[RhythmAce]

Without knowing more about this app, it's hard to come up with a solution. In most cases, you need to install packages as root if they are going to be system wide. For example, if you install an app as installguy, then the executables will be put in installguy's path. This would cause us to use your solution. Now, if we install the same app as root, then the app can be made available to everybody. An example of this are all the packages installed for the desktop environment. Where I'm confused is that most complex apps have their own user and admin database. Can you get a little more specific on how this app works?

 

[maxthedork]

It's a tiered portal database that plugs into an oracle database running on HP-UX. The portal presents a web interface that is customizable for end users and also allows us to present tabs for different portlets. We have a backend "resource" server, a middle-tier "calendar/mail" server, and two load-balanced "portal" (web) servers. Load balancing is done through an F5 appliance.

My biggest gripe is that I have to set up users on each of these servers, and there's no central management on the Linux side of things. On the portal side, it's just one user and easy administration setup but on the backend there's a lot of things we need to do and that's when we use the "installguy" user.

You can look up this application, just Google "Luminis." It's a SunGard Higher Education product.

 

[pentode]

and there's no central management on the Linux side of things

Looking at the bigger issue, you might want to look into LDAP for Linux if you haven't already. It can handle administration of multiple Linux servers.

 

[maxthedork]

We use LDAP for the portal but not for Linux server administration.

 

[exsnafu]

as for installguy vs remoteguy you should do the following:

use sudo as was suggested to track sudo'ing to the installguy ID.

then you can also further isolate/track their activity by setting up specific shell history files dependent on your basename login name:

export base=${base:-$(who am i | awk '{print $1}')}
export HISTFILE=$HOME/.history/$base.history

or somesuch, you get the idea.. but with this kind of setup you a) know who has su'd to the application ID and its generally very simple to see who issued what commands as that ID for auditing.