2

On Un*x, Is it ever a good idea to have one userid that many different people log into when they do stuff?

Often I'm installing software or something on a Linux or BSD system. I've developed software for 24 years now, so I know how to make the machine do what I want, but I've never had responsibility for maintaining a multi-user installation where anyone really cared about security. So my opinions feel untested.

Now I'm at a company where there's a server that many people log into with a single userid and do stuff. I'm installing some software on it. It's not really a public-facing server, and is only accessible via VPN, but it's used by many people nonetheless, to run tests on custom software, things like that. It's a staging server.

I'm thinking that at the very least, using a single user obscures an audit trail, and that's bad. And it's just inelegant, because people don't have their own spaces on the server.

But then again, with more userids, maybe there's a greater chance that one can be compromised, allowing attackers to gain access.

?

3 Answers 3

1

Use separate UIDs. Having multiple users with the same UID make it impossible to tell who is who. Any reverse lookups from UID to logname become unreliable.

One standard solution to your requirements is to install and use sudo. sudo allows you to grant the ability to run programs as a different user to any users or user groups you wish. The sudoers file allows significant flexibility in who is permitted to do what. Actions performed using sudo are usually logged.

Some distributions lock root and use sudo to allow users to perform actions which need to be done as root.

It is possible and common to allow users to execute su, or use the -i option to become another user. This reduces the audit trail somewhat, but tied with process accounting you can get a very good audit trail.

Remember that anyone with root access can usually work around your audit trail. Don't give people root access unless you trust them.

5

As you've said, for auditing purposes, this is extremely non-ideal. By having multiple userids, you allow yourself to see who is doing what at what time. That's not to say it is foolproof. Nothing is really stopping them from either telling each other their credentials or other users stealing credentials.

If you make custom software, I see your biggest risk coming from someone wondering what rm -rf does in the root directory, among other potentially terrible things (but you have tested backups....right?)

1
  • 1
    +1 - Sharing credentials, UIDs, etc, eliminates the possibility of auditing. It's not a good idea. Don't do it. Nov 23, 2011 at 19:25
0

i am think that it is totaly depend on what your benefits are, it will take time to arrange the accouts & set the permissions and so on, and if you are set it carefully you can set groups of users so even it some account get hacket it isn't neccerly impact the rest of the system, but this things are part of security so you should concentrate at what is your needs.

I think that the best way for you would be to create 2 or 3 groups and one userid in each so that you can at least manage the groups (which take less time & effort than seperate userid for each user), and give you some ability of permissions and auditing.

1
  • This would still require the same amount of planning because you would have to determine who is in what group, and at that point, you might as well create accounts for each user in those groups. With only one per group, you still have the same problem of not knowing who is doing what, just in a smaller scope.
    – Tablemaker
    Nov 23, 2011 at 20:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .