Should we be using the /users tag? And how do we account for /accounts?

Question

The tag users feels a bit vague to me. It covers several related topics, including:

• user account metadata (password, shell, …), e.g. 1 2 3
• user account databases, e.g. 1 2
• privileges of a user (the files they can write, etc.), e.g. 1 2
• file ownership, e.g. 1; often chown is used instead

We also have accounts, which covers user account metadata and databases. I don't know when to use accounts and when to use users for this meaning (except that accounts can also apply to groups).

Should we split users? If so, should we unify one of the meanings with accounts?

As for group, it feels more tame to me. But it should be renamed to groups.

Answer 1

I think we could get away of groups, accounts, user(s) and group(s) if we used a single user-management for all questions about UID/GID and related topics, as they pertain the user administration of the kernel/system. Other usages, like databases, web servers and the like, that are not directly related with the user/group of the (file)system itself should use their respective applications tags, like mysql, apache, pam, etc.

Is the most simple solution I can find, which would have the most desired effect and prevents confusion.

Answer 2

I do associate users with, users in /etc/group. IIRC this used to be the initial group account for when new user accounts were made (before the practise of making a group with the username for each user became widespread).

At least this questions seems to use it that way.

I don't think that that once case warrants keeping that tag around. If there are more such cases a more generic initial-group would be more appropriate (i.e. describing its function not necessarily the actual name used). During a re-tag action one could retag users to this for appropriate questions and tally at the end to see whether initial-group should be a keeper.

Answer 3

I could be oversimplifying this:

Users - Attached to a human

Accounts - Not Attached to a human

User in a database would be accounts since it is overshadowed by account used by the database itself. Hopefully, we aren't running our services as personal users anymore.

Answer 4

I am going to disagree with DarkSheep, As much as it would be nice to have a good unix-wide distinction between users and accounts (bob is a user, apache is an account) this is not a distinction that really exists outside a small number of administrative tools. The confusion between users (Bob, a man who has less hair than he wishes), user accounts (bob, the login for the man who wants more hair), pseudo-users (the thing the computer thinks is out there, maybe), and pseudo-user accounts (the user account set aside for the web server) is not well defined on a truly global scale (although some distributions are trying to draw a line in the sand)

If we were to adopt site specific definitions (which I think would be a good thing as long as we recognise that these definitions are not fully accepted) I would propose the following:

User: PEBKAC.

• System User Account: The association of data identifying a user returned by pwgent including UID, GID, username, and related information, but specifically not including password related information.

• Application User Account: any user account used by an application that is not returned by pwgent.

• Pseudo-user Account: Any special case of System User Account that does not have a corresponding User.

• Regular User Account: Any System User Account associated either with an individual or organization.

Don't even get me started on groups Which are an even bigger mess with:

• User group:

  1. organization for supporting users
  2. the group with the same name as the user
  3. a group containing real pebkac users (which sometimes is called users)

• Group user: a user that is a member of a specific group

• Administrative group: a group of users (pebkac) that have permissions based on group membership.

• system group: a group without real users (ie bin, games, lpr)
• system user group (apache)

Feel free to improve this.