Sadly, none of those operations were ever standardized.
Some operating systems offer this functionality as part of the OS, like Linux, but even if your Linux system includes them, over time and across Linux distributions the tools and their names changed so you can not really depend on a standard set of tools to do those tasks.
You need to have a per-operating system set of tools.
newgrp only gives you access to a group that you already have access to. Sounds useless? Basically, yes. It's mostly a leftover from the days when a process couldn't be a member of multiple groups. You can also gain access to a group that's protected by a password, but that's extremely uncommonly used.
From the kernel's point of view, each process is in one or more groups. setgid can only be used when running as root or in setgid programs (to swap between the real (run-by) and effective (run-as) groups). The kernel doesn't know about user and group databases.
User and group databases (/etc/passwd, /etc/group, /etc/security/group.conf, LDAP, …) are managed by login, su and other programs that manage logins and privilege elevation, often through PAM. When you log in, you get assigned to the groups listed in /etc/passwd, /etc/group, and other files through pam_groups; the process looks like this:
gid_t groups[…] = /*extra GIDs computed from /etc/group and so on*/;
setgroups(sizeof(groups)/sizeof(gid_t), groups);
setgid(gid); /*main GID read from /etc/passwd*/
setuid(uid);
execve(shell, "-sh"); /*shell read from /etc/passwd*/
In words: renouncing root privileges (i.e. changing to the target user) is done after all other privilege management, just before invoking the user's shell. After the process is no longer running as root, it can't gain any extra groups.
If you've just added a user to a group, this will take effect the next time the user logs in. If you start another session by logging in in another terminal or over ssh, the processes in that session will have whatever groups your user was in at the time you logged in. You can use the groups or id command to see what groups you (meaning the particular process you launched groups from) are a member of.
So, I've answered your explicit questions (newgrp is doing its job, which isn't what you thought). I may or may not have solved your problem. It's unusual for applications that don't log you in to look up user and group databases; normally access permissions would be decided by checking whether the requesting process is a member of the relevant group. If you have a problem with a particular application, tell us which.
Best Answer
One might easily think that
usersis meant to be assigned to every non-daemon user, but that's not the case. Remember that groups are a mean to control permissions...if that were to be the case wouldn't belonging tousersbe meaningles? Imagine trying to make use of that group: to keep a file that belongs to groupusersprivate, you would need to assign it the same permission bits to the "group" as you would to "others", as every user would be part of that group. Redundant and useless, if not plain annoying.In reality, the
usersgroup exists just to be assigned to users which don't need to belong in any other group, as far as permissions are concerned. It basically exists just because every user must be at least part of a primary group (which you can find in/etc/passwd)...think ofuserslike a "fallback", if no group is assigned to an user. (theuseraddutility actually uses it as a fallback, if no group is given and homonym groups are disabled)For this very same reason, you will find that the
usersgroup does not usually get any particular permission on the filesystem: no administrator will ever create a file which is owned by theusersgroup, (if he wanted to allow any user to manipulate a file, he would instead usechmod o+rwx). So, it doesn't matter if you belong to that group or not, it will not give you any special permissions...that's why, unless you have no other group you're being assigned to, there's absolutely no need to assign an user to it (its insignificance, permission-wise, is very similar to that ofnogroup).As for the
othergroup, i don't see it neither in my fresh CentOS 7 installation nor in my Ubuntu 14, so i'm guessing the document you read refers to theotherportion of the Discrectionary Access Control bits (the last octal digit you can edit withchmod), or a group created and used by some application...so, asking for the reason for its existence is like asking why the group "www-data", created by nginx, exists: it just depends on what the application that created the group wants to do with it.