Unix Groups Administration

Unix groups as we know them were invented by BSD. Essentially a group is a role. In pre-BSD Unix a user can belong only to a single group (primary group in modern terminology) and needs explicitly switch groups with command newgrp if he/she needs to assume new group identity. This was a mechanism very similar to the way a user switched identity with su. BSD introduced the ability for a user to belong to multiple groups, extending group concept to the level we now find in all modern Unixes, but unfortunately the implementation was subject to three serious limitations:

1. Any file can be owned by just a single group. That subverts granularity of access unless the number of groups are close to the number of files and creates the need for Unix Access Control Lists (ACL). Which are equally problematic (and dual ownership scheme represents significant security risk), but at least can solve this problem of interoperability with Microsoft Windows. There is no surprise that they are mainly are used by Samba. 
2. Groups cannot contain other groups as members (no nesting). This is a very serious deficiency, almost a blunder. For example, group staff  should generally be metagroup consisting of the members of the wheel  group (administrators), operator  group (operators), dba  group (data base administrators) and possibly some other users groups.  Without ability to nest groups both staff and constituent groups need to be maintained simultaneously, which create possibilities for discrepancies.

In old versions of Unix there was also a limit (usually 16 or 32) of groups that can be associated with an individual user (or process).  In other words any user can't belong to more then, say, 32 groups. That make fine grain separation of data space using very small groups of files difficult and that's why all modern Unix implementation contain ACLs in addition to traditional groups. In  Linus with kernel 2.6.3+ each user can belong to 64K groups.  Another limit on group memberships is imposed by NFS. The NFS RPC protocol can truncate number of groups per user/process even further than the number supported by the underlying OS.

As a result it must be openly stated that groups membership in Unix usually is taken "as is" and is not customized or enhanced by system administrators. In other words, sysadmin usually do not engage in new group definitions outside a couple of custom and often specific to the organization groups. Often they create an umbrella group for some subset of superset of the group staff. If this group is used as a primary group for user accounts that creates "unwanted sharing" which can be a nasty security vulnerability. Ability to view files for example in home directories of all or large subset of users is a pretty serious serious security weakness.  The concept of User Private Groups  was invented (and implemented in Red Hat but not in Suse) to avoid this vulnerability.

In this sense Unix groups, while a powerful concept, in practice proved to very weak, almost useless, role granting implementation for file access permissions. The area were they proved to be useful is mainly in grouping files belonging to various application. In most such cases group is identical to the owner. That's why most modern applications usually define both special user ID and the group (oracle:dba, db2, webshere, apache, etc). In this case group membership provides convenient write access to the configuration files and data files for the application without switching identity (for example, group www  can be used for editing web server files, while group dba can be used for editing oracle configuration).

Each user belongs to two types of groups:

• a primary group (a group that is used in /etc/passwd  for this particular user)
• the secondary groups (optionally). In Linux there are some semi-system groups into which each new user is enrolled automatically such as games...

Each Unix user has so called primary group which is is defined during the account creation from the list of existing groups listed in /etc/group  and is stored in /etc/passwd  file. This primary group concept is often a source of security vulnerabilities especially if all users are assigned "one-size fits all" primary group like staff. A more modern way to administer primary groups in Unix is to have for each user unique primary group (with GID equal to UID). That solved implicit security problem with shared primary group mentioned above.

I think this concept was pioneered by Red Hat which calls this concept User Private Groups (UPG). The main advantage of UPG concept is a fine granularity of group permissions: all permissions are assigned via secondary groups which leads to tighter and simpler security model.

Defining groups for large systems is similar to defining roles. Taking into account fundamental limitation that a file can be assigned only to a single group this is a difficult task, which becomes especially difficult as we deal only with file access and that is usually only part of the role. Generally small groups are best: it goes without saying that group membership should not be excessive (staff group is a classic example of abuse of groups in Unix). The goal is the separation of filesystem space into several sub-domains according to the roles used on the system. It is better to have limited number of small, stable, well understood groups. A large number of ad-hoc group present of the system is usually a symptom of poor security and poor administration is. Often that means that instead of thinking about the separation of filesystem space, the administrator is trying to solve each newly discovered problem of file access with a new group creation. Such ad-hoc activity is better performed with ACLs. The latter can be viewed as a group membership assigned to a single file. For example security group often is assigned read access to such files as /etc/shadow. You can do it by changing the group membership of the file to this group or, better, leaving group membership intact and using ACLs.

Good group definitions are often related to job functions (roles) instead of organizational structures; for example, there can be a special group for operators, for data base administrators, for web server and webshere administrators, etc. This is complex task and that's why system administrators usually ignore group concept as it requires additional efforts to establish and to understand, but provides minimal return on investment. And this refusal to play with groups on the system and leaving intact groups created by the system and applications installed is probably a right approach. As we discussed above, in most cases when additional access is required to a small number of files (especially system ) it is easier to use ACL to grant such access, then play with groups model. But there is no free lunch. ACLs also has drawbacks and create hidden second layer of file access permissions that can be used to subvert security instead of improving it.

Theoretically groups can also be used to restrict access to sensitive information or specially licensed applications to a particular set of users: for example, in most commercial Unixes only users who belong to the kmem group can examine the operating system's kernel memory. The oracle group is commonly used to allow only registered users to execute the commercial Oracle database program. And a sources group might be limited to people who have signed nondisclosure forms so as to be able to view the source code for some software. In reality switching identity using su is almost a universal way of dealing with such problems.

It is important to understand that there are multiple way to abuse the concept of the group membership and it is easy to decrease the security of the system by misusing it. Write access via broad-based group is almost as harmful as write access to the world. It can be argued that no (or minimal) additional group definitions are better (more secure, less hassle) than poorly planned group definitions. Poorly planned groups tend to overlap in unexpected (and insecure) ways, especially if a new group is defined for every new situation. Our recommendations are:

1. Use User Private Groups concept, avoid sharing any primary group. In most cases such sharing is useless (or harmful, if you wish) concept that should be avoided. It is better to use User Private Groups A User Private Group (UPG) is a GID equal to UID. This allows for a fine atomic level of group permissions to be assigned for tighter and simpler security.
2. Use employee number or similar unique enterprise identity metric for UID (and GID) across all systems in the datacenter is a desired goal of Unix group. See UID policy In case non unique GID are used the problem of group mapping created interesting security vulnerabilities when you transfer files from one computer to another as root.
3. View new group definitions as role definitions at the enterprise level. Think before diving. Consider scenarios. Ask for advice. Once established and in use, group definitions are exceptionally difficult to change.
4. Home directories should be generally be "group averse" with permissions 750 and owned by user:root.
5. Dot files should be "group averse" too and generally should not allow reading or writing via group membership.
6. It is important to periodically (for example once a day from cron) verify existence of group writable files in system directories and changes in permissions for important system file. Such changes are usually a sign of intrusion. This can be done in the same script that detect world writable files.

Groups also can be classified into system groups (group that are used for partitioning ownership space and do not contain any "human" account as a member) and non-system groups (which often contain "human" accounts as members. Important non-system groups are:

• wheel primary system administrators (can be used with sudo to grant privileges to switch to root). On many systems (BSD, Linux) this group is created (but not populated) during the installation and as such can be considered to be a system group. On Solaris similar group is called admin.
• staff -- this group is often used as a primary groups for all employees that access the computer a security vulnerability (shared primary group means shared access to user created files, often including dot-files). It's generally a bad idea to use group "staff" as a primary group for employees accounts. User Private Groups is a better, more modern approach to the assignment of primary group.
• dba
• operator
• oracle
• www or apache
• Other application specific groups

Some UNIX Commands for Working with Groups

Large UID and GID Limitation Summary (from Solaris system administration guide)

Group Administration (from Solaris system administration guide)

User and group accounts control access to the system. The administration of user accounts and group accounts along with the passwords associated with these accounts is a key system administration activity.

... ... ...

Group accounts can be added, modified, or deleted using command-line utilities or by using the admintool(1M)  command. .

... ... ...

Creating a Group Using the groupadd Command

The groupadd(1M)  command provides a quick method to add a new group account. At a minimum, the group account name must be specified as a command-line argument. The groupadd  command supports two other command-line arguments. The first is -g gid, which used to specify the unique GID associated that should be associated with group. It must be a decimal integer. If GID is not specified, the next highest available GID is assigned. The other command-line argument is -o, which allows a duplicate GID to be assigned to the group.

The following example shows creating a group using the groupadd  command.

  groupadd -g 1000 newgroup 

Modifying a Group Using the groupmod Command

The groupmod(1M)  command is used to modify an existing group account. The command-line arguments are identical to the groupadd  command-line arguments, except the new group account name is specified using -n name  if the group account name is being modified. The following example shows how to use the groupmod  to change group newgroup  to ngroup.

  groupmod -n ngroup newgroup

Deleting a Group Using the groupdel Command

The groupdel(1M)  command is used to delete a group account. The group account is specified as a command-line argument.

  groupdel ngroup

NEWS CONTENTS

• 20210508 : LFCA- Learn User Account Management Part 5 ( May 08, 2021 , www.tecmint.com )
• 20140225 : Access Control Lists In Linux Filesystems ( February 25, 2014 , Slashdot )
• 20140225 : Securing Debian HOWTO Chapter 8 Frequently asked Questions ( )
• 20111014 : Nasty surprise with the command cd joeuser; chown -R joeuser:joeuser .* ( Oct 14, 2011 )
• 20080506 : freshmeat.net Project details for Silk Tree by Aleksandr O. Levchuk ( freshmeat.net Project details for Silk Tree, May 6, 2008 )
• 20080506 : GeodSoft How-To Hardening Systems, Users, Groups and Security ( GeodSoft How-To Hardening Systems, Users, Groups and Security, )
• 20080506 : SG245962 ( SG245962, )
• 20080506 : Alternatives to Using Unix Groups ( Alternatives to Using Unix Groups, )
• 20080506 : maestrouser Problems with Unix Groups ( maestrouser Problems with Unix Groups, )
• 20080506 : Re: Use of Groups in Unix Systems Administration ( )
• 20080506 : Re: Use of Groups in Unix Systems Administration ( )
• 20080506 : 1991 Summary UNIX groups ( 1991 Summary UNIX groups, )
• 20080506 : Slashdot Nested Groups on Unix ( Slashdot Nested Groups on Unix, )
• 20080506 : Corporate solution ( softpanorama.org, )
• 20080506 : Preprocessor ( softpanorama.org, )

Old News ;-)

[May 08, 2021] LFCA- Learn User Account Management Part 5

May 08, 2021 | www.tecmint.com

The /etc/gshadow File

This file contains encrypted or ' shadowed ' passwords for group accounts and, for security reasons, cannot be accessed by regular users. It's only readable by the root user and users with sudo privileges.

$ sudo cat /etc/gshadow

tecmint:!::

From the far left, the file contains the following fields:

• Group name
• Encrypted Group password
• Group admin
• Group members

[Feb 25, 2014] Access Control Lists In Linux Filesystems

February 25, 2014 | Slashdot

ACLs *ARE NOT NECESSARY* (Score:5, Insightful)
by Captain_Carnage ([email protected]) on Sunday February 25, @06:30PM EST (#82)
(User #4901 Info)

There are two basic access needs that people need to have to data: the ability to READ the data, and the ability to MODIFY the data. In ALL cases (at least, in all useful cases), these priviledges can be granted using standard Unix permissions.

Let's say you have a directory full of files, and you need some people to be able to write to these files (which implies they'll also need to be able to read the files, to verify their changes), and you have another group of people who needs to be able to read the files. Everyone else in the organization should have NO access. This is the most complicated case.

Can this be done with standard Unix permissons? At first glance, you might think that you can't, because the only permissions provided in Unix are User (owner), Group, and Other (world). You can't control the access for a second group, which is what you need, right?

However, the answer is YES! You can do this. Here's how:

Create one group each for the people who need to be able to read the files, and write the files. For simplicity of the example, let's call the groups "read" and "write" respectively.

Now, add every user who needs read access to those files to the "read" group, and add all users who need write access to BOTH groups.

Now, create a top level directory, like this (only ownerships, permissions, and the name are shown for brevity):

drwxr-x--- root read topdir

# mkdir topdir
# chgrp read topdir
# chmod 750 topdir

Both groups we created can cd into this directory (because we added the "write" group to the "read" group, remember?). Now, under that directory, create one or more directories where your data will be stored, like this:

drwxrwsr-x root write datadir

# cd topdir
# mkdir datadir
# chgrp write datadir
# chmod 2775 datadir

The '2' sets the SGID bit on the directory, which forces all files created in this directory to be created group-owned by the "write" group (it copies the group ownership of the directory to all new files in it). It will also make new files created in this directory group writable by default (again, copying the group permissions from the directory).

You might also want to prevent users from deleting files they don't own, by setting the sticky bit on the directory, which will make the '2' a '3' instead.

Now, users in the "write" group can create and write to files in this directory, and users in the "read" group will be able to read them, because they will be readable by other (world). However, everyone else will NOT be able to read them, because in order to do so, they would have needed to be in the "read" group in order to cd into topdir to get to datadir (which is why we also included the users in the "write" group in the "read" group)!

Thus, your problem is solved. Do this for every directory where the groups of people who need each type of access are different. This is BETTER than ACLs because a) it is either the same amount of administrative effort than managing ACL's on a per-directory basis (but you manage group membership instead), or LESS administrative effort than managing ACLs on a per-file basis; and b) it FORCES you to organize your data heirarchically by who has access to it.

Get over ACLs... they are a waste of time and programming effort.

You could argue that you might want some third group of people to have write access ONLY, but the practical value of this is very limited. If you feel that you need this you are probably being silly or WAY too paranoid, even for a system administrator. Limiting people from reading data that they can over-write is generally nonsensical.

I don't deny that there are certain very narrow applications for that sort of access limitation, but the likelihood that such an application would also present the need to have groups with each of those access requirements (read, read/write, and write-only) seems rather slim.

ACLs are a Bad Idea (tm) (Score:1)
by tbray on Sunday February 25, @10:35PM EST (#110)
(User #95102 Info)

IMHO the original Unix user-group-world read-write-execute is one of the great 80/20 points in computing history.

The biggest downside of ACLs is their potential to reduce security due to inevitable human error introduced in dealing with the complexity.

Perhaps the canonical example is (old-fart alert) release X.0 (I forget X) of the late unlamented VAX/VMS, which ignored all the lessons of Linux except for (in early releases) the user-group-world model, except for they added an idiotic and useless "delete" access.

Anyhow, in X.0, VMS introduced ACLs; rather good and clean ones. Unfortunately, they screwed up the ACL on one of the core system name translation tables, and left it wide-open to subersion by anybody who wandered by and noticed.

I tend to think that this pattern is the rule rather than the exception... the cost of ACLs immensely exceeds the benefit, which isn't hard since it's often negative.

Cheers, Tim

ACLs are too cumbersome to maintain (Score:1)
by herbierobinson on Monday February 26, @03:07AM EST (#134)
(User #183222 Info)

http://www.curbside-recording.com/hrmusic/index.html

ACLs (at least in the implementations I've seen) are too cumbersome because they are too hard to maintain. One ends up having to copy the same ACl onto hundreds of directories (which is not so bad). The bad part is when have to change it: You need a tree walk program to make the change to all 100 directories.

One possibility would be to have some named object in the file system which defines a set of access rights. That named object would be referenced from all the directories (and optionally files) it should control access to.

There are a number of articals in the latest JACM on security which are very relevant to this discussion, too. One of them discussed making access control be task based rather than object based. In other words, users get assigned to one or more tasks (aka groups) and each task defines the access to all ojects somehow (the somehow is the hard part...).

ACLs are really not enough. (Score:4, Insightful)
by Anonymous Coward on Sunday February 25, @03:28PM EST (#59)

I've worked with ten or twelve operating systems at the system administration level, and I've done so in academic, corporate, medical, and military-industrial settings.

Most of the proprietary Unices (if you count different *nixen as separate OSes, double the OS count given above) have their own lame, incompatible implementations of ACLs. These are typically layered over the antique Unix rwxrwxrwx scheme.

"rwx" is insufficient. People often exhort others to "think unix" - and when you are talking about pipes & I/O redirection, or any of the other wonderful features of Unix, that's great. But if you "think unix" to the extent that you can't see how fundamentally LAME the unix access control mechanisms are, you are crippling yourself. To put it in perspective, consider the IBM MVS file protection system RACF - in RACF, you cannot grant a user write permission without also granting read permission. This is partially because of the underlying architecture of MVS, but that doesn't mean it's not lame and restrictive. However, most hardcore mainframers literally cannot conceive of a situation where they'd want write and not read.

Novell has the most advanced and useful system of file attributes I am aware of. For example, "create" and "write" are separate - this allows the creation of dead-drop boxes; folders where a user can create a file but cannot afterwards modify it. If you can't conceive a situation where you could put this to use, you are "thinking unix" to the point of wearing blinders. NOTE: the forgoing statement will cause this post to be labeled "flamebait" and modded into oblivion by self-righteous Berkleyites >:^} while simultaneously generating dozens of "oh yeah name one" followups.

There are many other aspects of the Novell system of file protection and user rights that are very advanced. Consult your local guru, but I'll mention "rename inhibit" as one useful ability. If Stef Murky, excuse me, Jeff Mirkey, ever gets his MANOS opsystem going under the GPL I personally will immediately convert to his Novell-clone filesystem. Even DEC VMS does not compare, and the VMS access control mechanisms beat Unix hands down.

I don't recommend Novell because it's not Open Source and because the complexity of X500 or NDS type "directory" systems adds instability and management overhead that is seldom warranted to achieve concrete goals. That being said, as the world becomes increasingly networked the previous statement becomes increasingly less accurate.

LDAP interfaces to SQL backends like MySQL and Postgres will eventually be the way to go (but not today, and ADS will never fit the problem space). The one warning I would sound is that when you keep file data and file attributes in separate places - as many systems do - you markedly decrease the robustness of your system. User data in the user directory, file attributes in the file header, is a better idea. Just like it's a better idea to put the comments in the source code than in a separate documentation file (don't get me started about that stupid practice).

Sorry my .02 pence is so lenghty. I could rant some more, but I think I got the major point across - ACLs on a "rwxrwxrwx" system is like streamlining a 1954 Volkswagen Beetle.

Re:ACLs *ARE NOT NECESSARY* (Score:3, Insightful)
by coyote-san on Sunday February 25, @07:52PM EST (#91)
(User #38515 Info)

There are three small problems with this scheme.

First, you run into combinatorical explosion in the real world. Try running through your example in a small CS department with 5 professors, 50 students, and each student enrolled in three classes. Everyone has to work in teams, but the teams are different in each class. So each student needs to see his own files, and *some* of the files in 6-12 other user accounts (with team sizes from 3-5 people). He can't see all because that would be "cheating."

Now maintain that over 5 years, as students enroll, graduate, etc.

The second problem is that ACLs often support much more than simple read/write/execute. There's "modify" vs. "append." That is so important that ext2 supports "append-only" as one of the extended attributes. There's "change attributes (chattr)" as a separate permission than "write." Some ACL systems even control your ability to "stat" a file, to determine its ownership, size, time of access, etc. Some of this can be handled by your scheme, but it makes it much more complex.

The final problem is that ACLs are far more powerful than most implementations would suggest. Besides being able to grant - or revoke - access to individuals for read/write/execute/modify/append/delete/chattr/sta t, I've seen ACL specs which allowed restriction based on time-of-day, day-of-week, and even access terminal (local vs. network). You can use 'cron' to automatically change some bits, but it's hard to set it up so that, e.g., the faculty can play games any time, the staff can play them after hours, and the students can play them on weekends.

For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken

Re:ACLs *ARE NOT NECESSARY* (Score:1)
by Captain_Carnage ([email protected]) on Sunday February 25, @10:53PM EST (#111)
(User #4901 Info)

In the real world, in most cases, going through the trouble I describe is not necessary. It is only necessary in a (usually) small number of cases where there are two distinct groups of people that require two different types of access.

In the University example that you describe, it is unlikely that all of these classes will have people working in teams for every assignment. In many such courses, the students' work is entirely individual.

In those cases where it is not, you simply need to create a Unix group for each team. All of the files for that team's project are kept in a central project-related directory. There is no reason whatsoever for any user not in that group to have access of any kind to the files of that group's project, so a more complicated scheme is not necessary.

Moreover, the classes offered from semester to semester don't tend to change much, so for the most part the groups will stay the same too, so you're not likely to need to spend a lot of time maintaining that, nor are you likely to run out of groups, even in a much larger CS department.

In the "real world", your first case just isn't really a problem. I learned how to use Unix permissions from the sysadmin of my college, whose CS department has over a thousand users, who successfully employed this tecnique for years.

The second case, modify vs. append: To me the latter is just a special case of the former. I personally see no reason why one should be treated differently from the other. If you have a compelling reason why someone should be allowed to append data to a file, but not modify the data that's already in the file, I'd certainly like to hear it.

Your permission to stat a file is controlled by whether or not you have read access to the directory the file is in. What legitimate reason can you suggest for preventing a user from seeing SOME files in a directory they legitimately have access to, but not others? What practical purpose does this serve?

Re:ACLs *ARE NOT NECESSARY* (Score:2)
by Baki ([email protected]) on Monday February 26, @08:31AM EST (#143)
(User #72515 Info)

Real world problems that suffer from mentioned combinatorial explosion, are too complex: The business model in such cases should be simplified. The sulution to complex access schemes is not to add a complex technical implementation, but to simplify the scheme.

The (many) times I've seen ACL's in action to implement overly complex access control schemes, it bacame chaos, and nobody knew anymore who was allowed to see what, and why the ACL's were the way they were. Maybe massive beaurocratic measurements could prevent chaos in such cases, but one had better rethink the way permissions are granted.

As for modify/append: There are a couple of very specific (system) tasks where append-only might be useful, especially for logfiles that intruders may not tamper with. But for general purpose use, I don't see the need. Append-only can just as well be implemented as a write-only directory (a la /tmp on Unix systems) where a user can "append" a record by creating a new file. Then cat them all in order of mtime, and you have about the same.

Time-dependant access etc is insane to administer, and again IMO the business model should rather be simplified.

Maybe ACL's are nice for control-freak type of system administrators that don't have much work to do, but for normal situations they're no good.

Securing Debian HOWTO Chapter 8 Frequently asked Questions

8.4 Questions regarding users and groups

8.5 Are all system users necessary?

Yes and no. Debian comes with some predefined users (id < 99 as described in Debian Policy) for some services so that installing new services is easy (they are already run by the appropriate user). If you do not intend to install new services, you can safely remove those users who do not own any files in your system and do not run any services.

You can easily find users not owning any files by executing the following command (be sure to run it as root, since a common user might not have enough permissions to go through some sensitive directories):

     cut -f 1 -d : /etc/passwd |
     while read i; do find / -user "$i" | grep -q . && echo "$i"; done

These users are provided by base-passwd. You will find in its documentation more information on how these users are handled in Debian.

The list of default users (with a corresponding group) follows:

• root: Root is (typically) the superuser.

• daemon: Some unprivileged daemons that need to be able to write to some files on disk run as daemon.daemon (portmap, atd, probably others). Daemons that don't need to own any files can run as nobody.nogroup instead, and more complex or security conscious daemons run as dedicated users. The daemon user is also handy for locally installed daemons, probably.

• bin: maintained for historic reasons.

• sys: same as with bin. However, /dev/vcs* and /var/spool/cups are owned by group sys.

• sync: The shell of user sync is /bin/sync. Thus, if its password is set to something easy to guess (such as ""), anyone can sync the system at the console even if they have no account on the system.

• games: Many games are sgid to games so they can write their high score files. This is explained in policy.

• man: The man program (sometimes) runs as user man, so it can write cat pages to /var/cache/man

• lp: Used by printer daemons.

• mail: Mailboxes in /var/mail are owned by group mail, as is explained in policy. The user and group is used for other purposes as well by various MTA's.

• news: Various news servers and other associated programs (such as suck) use user and group news in various ways. Files in the news spool are often owned by user and group news. Programs such as inews that can be used to post news are typically sgid news.

• uucp: The uucp user and group is used by the UUCP subsystem. It owns spool and configuration files. Users in the uucp group may run uucico.

• proxy: Like daemon, this user and group is used by some daemons (specifically, proxy daemons) that don't have dedicated user id's and that need to own files. For example, group proxy is used by pdnsd, and squid runs as user proxy.

• majordom: Majordomo has a statically allocated uid on Debian systems for historical reasons. It is not installed on new systems.

• postgres: Postgresql databases are owned by this user and group. All files in /var/lib/postgresql are owned by this user to enforce proper security.

• www-data: Some web browsers run as www-data. Web content should *not* be owned by this user, or a compromised web server would be able to rewrite a web site. Data written out by web servers, including log files, will be owned by www-data.

• backup: So backup/restore responsibilities can be locally delegated to someone without full root permissions.

• operator: Operator is historically (and practically) the only 'user' account that can login remotely, and doesn't depend on NIS/NFS.

• list: Mailing list archives and data are owned by this user and group. Some mailing list programs may run as this user as well.

• irc: Used by irc daemons. A statically allocated user is needed only because of a bug in ircd -- it setuid()s itself to a given UID on startup.

• gnats.

• nobody, nogroup: Daemons that need not own any files run as user nobody and group nogroup. Thus, no files on a system should be owned by this user or group.

Other groups which have no associated user:

• adm: Group adm is used for system monitoring tasks. Members of this group can read many log files in /var/log, and can use xconsole. Historically, /var/log was /usr/adm (and later /var/adm), thus the name of the group.

• tty: Tty devices are owned by this group. This is used by write and wall to enable them to write to other people's tty's.

• disk: Raw access to disks. Mostly equivalent to root access.

• kmem: /dev/kmem and similar files are readably by this group. This is mostly a BSD relic, but any programs that need direct read access to the system's memory can thus be made sgid kmem.

• dialout: Full and direct access to serial ports. Members of this group can reconfigure the modem, dial anywhere, etc.

• dip: THe group's man stands for "Dialup IP". Being in group dip allows you to use a tool such as ppp, dip, wvdial, etc. to dial up a connection. The users in this group cannot configure the modem, they can just run the programs that make use of it.

• fax: Allows members to use fax software to send / receive faxes.

• voice: Voicemail, useful for systems that use modems as answering machines.

• cdrom: This group can be used locally to give a set of users access to a cdrom drive.

• floppy: This group can be used locally to give a set of users access to a floppy drive.

• tape: This group can be used locally to give a set of users access to a tape drive.

• sudo: Members of this group do not need to type their password when using sudo. See /usr/share/doc/sudo/OPTIONS.

• audio: This group can be used locally to give a set of users access to an audio device.

• src: This group owns source code, including files in /usr/src. It can be used locally to give a user the ability to manage system source code.

• shadow: /etc/shadow is readable by this group. Some programs that need to be able to access the file are set gid shadow.

• utmp: This group can write to /var/run/utmp and similar files. Programs that need to be able to write to it are sgid utmp.

• video: This group can be used locally to give a set of users access to an video device.

• staff: Allows users to add local modifications to the system (/usr/local, /home) without needing root privileges. Compare with group "adm", which is more related to monitoring/security.

• users: While Debian systems use the user group system by default (each user has their own group), some prefer to use a more traditional group system. In that system, each user is a member of the 'users' group.

---

8.5.1 What is the difference between the adm and the staff group?

'adm' are administrators and is mostly useful to allow them to read logfiles without having to su.

'staff' is useful for more helpdesk/junior sysadmins type of people and gives them the ability to do things in /usr/local and create directories in /home.

[Oct 14, 2011] Nasty surprise with the command cd joeuser; chown -R joeuser:joeuser .*

This is classic case of side effect of dot .* along with -R flag which cause complete tree traversal in Unix. The key issue here is not panic. The recovery is possible even if you do not have the map of all files permissions (and you better do it on regular basis). The first step is to use

for p in $(rpm -qa); do rpm --setugids $p; done

The second is to copy remaining ownership info from some similar system. Especially important is to restore ownership in /dev directory.

Similar approach can be used for resoring permissions:

for p in $(rpm -qa); do rpm --setperms $p; done

Please note that the rpm --setperms command actaully resets setuid, setgid, and sticky bits. These must be set manually using some existing system as a baseline.

[May 6, 2008] freshmeat.net Project details for Silk Tree by Aleksandr O. Levchuk

Ruby script

Silk Tree propagate /etc/passwd and /etc/group files from a master to a list of hosts via SSH. Neither the sending nor the receiving end connect to each other as root. Instead there is a read-only sudo sub-component on the receiver's side that makes the final modifications in /etc. Many checks are made to ensure reliable authorization updates. ACLs are used to enforce a simple security policy. Differences between old and new versions are shown. Two small scripts are included for exporting LDAP users and groups.

GeodSoft How-To Hardening Systems, Users, Groups and Security

For a server application like a web site where content corresponds to organizational units, NEVER use standard OS system accounts to manage access to application data. Don't even use an account such as OpenBSD's "staff" as an equivalent for employees. If you examine /etc/login.conf you'll see that "staff" is a relatively privileged group. They can login when others cannot and have higher limits on most resources than other groups. OpenBSD's staff group is intended for computer staff, i.e. administrators and backup operators and maybe a webmaster. It's not an equivalent to "employees". If you need such a group, create it.

SG245962

In larger installations, good system administration usually revolves around group definitions. Guidelines for forming groups should be part of any security policy. Defining groups for large systems can be quite complex and is beyond the scope of this document. Users will often belong to more than one group, but group membership should not be excessive. One goal is to have a moderate and stable number of groups. A symptom of poor security and poor administrative planning is a constantly increasing number of groups.

If at all possible, group definitions should extend across all system platforms: MVS, UNIX, NetWare, and so forth.

That is, a given group name should have the same members, the same security associations, and similar administration on MVS and UNIX and LAN systems.

Good group definitions are often related to job functions instead of strict organizational structures; for example, there may be a group for secretaries, regardless of their department. This is a difficult goal. System administrators will seldom do it voluntarily because it requires endless coordination and meetings with other system administrators.

Nevertheless, it is a good goal because it forms and helps enforce a meaningful security policy for an enterprise. The standard UNIX file security controls, the permission bits, provide very limited granularity. The AIX ACL functions extend this and are discussed in 5.6, "Access control list (ACL)" on page 100.

Well planned use of group definitions substantially extends the usefulness of the permission bits.

However, it must be admitted that most UNIX administrators ignore group definitions, or, at best, define groups for use only within their system.

It can be argued that no (or minimal) group definitions are better (more secure, less hassle) than poorly planned group definitions.

Poorly planned groups tend to overlap in unexpected (and unsecure) ways, especially if a new group is defined for every new situation. Our recommendations are:

• If possible, coordinate group definitions in as large a context as possible. At the enterprise level is best.
• At whatever level the groups are defined, think! Consider scenarios. Ask for advice.
• Once established and in use, group definitions are exceptionally difficult to change.

Alternatives to Using Unix Groups

maestrouser Problems with Unix Groups

Re: Use of Groups in Unix Systems Administration

Greg Vinall ([email protected])
Tue, 26 Mar 1996 19:54:32 -0800

• Messages sorted by: [ date ][ thread ][ subject ][ author ]
• Next message: Shu De Liang: "Look for two group members"
• Previous message: Greg Vinall: "'This' group"
• Maybe in reply to: David Williams: "Use of Groups in Unix Systems Administration"
• Next in thread: David Jones: "Re: Use of Groups in Unix Systems Administration"

David Williams wrote:
>
> A not and some questions concerning the use of groups in Unix.
>
> To me the study material does not go into as much detail as I would like to see.
>
> Take this situation. A company has a computerised accounting system which
> consists of (a) an executable program and (b) an associated data file.
> Presumably the accounts staff are all in a group (say "accts"). The
> executable file has group owner "accts" and group permissions of r_x,
> allowing the accounts staff to run the program. But what about the data
> file? If it has the same group ownership and permissions as the executable
> (plus write of course), the accounts staff can access it when running the
> program (which is good) but could also access and corrupt it from outside
> the program e.g. from the shell, editor etc.

==========================================================================
We have a similar problem with our record management system, CARMS, which
runs on unix but is obviously not written FOR unix by those familiar with
unix. [BTW, support by the distributors and developers, ORTEX, is VERY POOR
and I would not recommend its purchase.] CARMS' data files are all writable
by those in the carms group which are the users of carms.

Several options are available:
1. Do as Oracle etc do. When a user runs Oracle it sets uid to oracle which
is the only user to have write access to the data files.
2. Do not give users access to the shell. On 'my' (I get maternal!) systems
99% of users do not shell access, instead running everything through a menu
system (custom written if you want a copy -- you just need a very simple C
compiler and the curses library)

==========================================================================

>> How is this overcome? Is the answer to give ownership of the program and
> data files to some other person e.g. the accounts supervisor, and set the
> SUID or SGID bits on the executable file?
>
> Second question, if the group ownership of a file is, say, "accts", does a
> user's current group have to be the same to access it? or is it sufficient
> that they be listed as a member of the group "accts" in the /etc/groups file?

==========================================================================
The user's id must be in the group in a file called /etc/logingroup (or is it
/etc/logingroups -- I should check the manual) which has the same format as
/etc/group. A user is automatically a member of all groups to which it
belongs in /etc/logingroup. A common practice is to symbolically link
/etc/group to /etc/logingroup so that any changes to the group file are
automatically reflected in the logingroup file.

I have a script which checks their membership to a group and gives a
user-friendly response if they are not, rather than giving the user a unix
refusal. You may have it if you wish.
==========================================================================

>> Thirdly, what happens if a user is created and given the same UID as root? I
> assume this gives them the same authority as root, which is surely what a
> lot of big organisations would want to do in order to share SA workload
> between several people, without having to change and re-issue the main root
> password when a person leaves. Does doing this have any other
> ramifications, indeed, does the system allow you to do it. I a person given
> the the UID of root creates a file, who is shown as the owner, root or that
> persons name?

==========================================================================
DEFINITELY NOT RECOMMENDED. Do not give another user UID of 0! root MUST
be aware that s/he is logged in as root. Giving another user id of 0
tends to encourage sysadmins to forget that they omnipotent. [This is not a
single user system where Nortons can undelete files etc.] Some systems do not
allow root to log in at all but must su to become sysadmin. A good policy!

Re: Use of Groups in Unix Systems Administration

Greg Vinall ([email protected])
Thu, 28 Mar 1996 07:09:46 -0800

• Messages sorted by: [ date ][ thread ][ subject ][ author ]
• Next message: David Jones: "Re: Use of Groups in Unix Systems Administration"
• Previous message: David Jones: "Re: 'This' group"
• Maybe in reply to: David Williams: "Use of Groups in Unix Systems Administration"

David Jones wrote:
>
> David Williams asks:
> > Second question, if the group ownership of a file is, say, "accts",
> > does a user's current group have to be the same to access it? or is it
> > sufficient that they be listed as a member of the group "accts" in the
> > /etc/groups file?
>
> Greg Vinall wrote:
> > The user's id must be in the group in a file called /etc/logingroup
> > (or is it /etc/logingroups -- I should check the manual) which has the
> > same format as /etc/group. A user is automatically a member of all
> > groups to which it belongs in /etc/logingroup. A common practice is to
> > symbolically link /etc/group to /etc/logingroup so that any changes to
> > the group file are automatically reflected in the logingroup file.
>
> I think you've just identified something that is specific to a
> particular version of UNIX. None of the Unices I've used make
> use of a file /etc/logingroups. Greg, you're using HP-UX aren't you?
>

Yes. I checked the manual, and logingroup is not a universal or POSIX
standard. But it sure makes scripting easy when you want to change a user's
group so that they may run WordPerfect for example.

David Jones continues:
> I would tend to use sudo. It's not standard but is available
> on most versions of UNIX and solves these and other problems.
>

-- 
lino
Systems Analyst
NSW Dept Land & Water Conservation
Home page: http://www.netwit.net.au/~lino

Bill Davidson [email protected]
Sun, 12 Dec 1999 20:53:14 -0400 (AST)

• Previous message: [nSLUG] Managing groups under UNIX.
• Next message: [nSLUG] Getting e-mails individually
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hi:

On Sun, 12 Dec 1999, Emmanuel Papirakis wrote:

> 	There is also a command called newgrp that toggles
> your effective group. Let's say that I belong to a
> special group called music with gid 600 and my current
> gid is 500. I just type newgrp music, if my name is in
> the list of users part of that group, it will just
> change me to this group id. If not, it will ask me for
> a password.

Just to be clear (and perhaps this was mentioned earlier in this thread,
and maybe it's obvious to everyone), newgrp changes your primary group,
i.e., it changes the gid of files you create.  It has no effect on your
group access permissions.  That is, in the example above, if there are
files with group owner music and, say, read access only for owner and 
group owner (eg. rw-rw----, or 660), and you are a member of group music 
but your primary group is gid 500, you don't need newgrp to read (or in 
this case write) that file.  I mention this only because I recently saw 
some confusion about it, among people who ought to have known better, on 
a newsgroup (c.o.l.d.s if you can believe it!).

Hope that wasn't too big a waste of bandwidth...

-- Bill

1991 Summary UNIX groups

The questions follow, interspersed with my summary of the replies;
I hope I have understood correctly! I have not actually pushed
at these limits yet, so cannot confirm/deny them.

> ...
> Good progress is being made with rationalising the uid/gid space
> and departments are willing and keen to conform to this.

Incidentally, several people enquired about this.

Primarily, we attempt to maintain good will with other departments,
pointing out benefits such as the automounter, if we adopt common
conventions (uid/gid, home directory structure ...).

Secondarily, but practically, we hold uid/gid information on all staff
and students in an INGRES database. We plan to allow all system
administrators to see enough of it to allow them to join users to
their own machines. The information we hold is itself gleaned from
files sent to us by the University Administration department.

> We have two (probably more!) unresolved questions about groups:
> 1. Group membership:
> a. Is there a maximum number of members to a group?
> (Counting through the "passwd" file.)

No known limit.

> b. Is there a maximum number of additional members a group may
> have? (Last field of an entry in the "group" file.)

For non-NIS, most respondents thought there was no limit, although one
thought that BUFSIZ (I assume "/usr/include/stdio.h") might be a limit.

For NIS, the "dbm(3x)" routines limit a single group entry to
just under 1024 bytes. Apparently it is possible to work around this
by creating several groups with the same GID.

> c. Do "a" and "b" interact?

No known interactions.

> d. Is there a maximum number of groups to which a user may belong?
> (SunOS pre-4.0 has a limit of 8 according to "group(5)";
> however, we are strongly encouraging our departments towards
> at least 4.0.3, preferably 4.1 or 4.1.1 .)

"/usr/include/sys/param.h" defines NGROUPS. From 4.0, this value is 16.
Some manufacturers go lower, some go higher.
BUT ... in a mixed environment using NFS, it is very unwise to exceed 8.

> 2. We follow SUN's defined groups:
> a. "staff" (group 10) is useful for installing applications
> because of directory ownership within SunOS;
> b. "operator" (group 5) is useful for disk backup (disk device
> ownership and permission) and shutdown procedures.
>
> But is all this SUN-specific? Do heterogeneous sites have
> other approaches and/or solutions?

Every vendor is different, so it seems, in defining their groups.
Generally, the solution adopted is either to live with it,
or to attempt to select the most popular machine as a local "standard"
and to (attempt to) coerce the others to fall in line.

More generally, there was a message on sun-managers on 6 Dec 1990
from "[email protected]" outlining approaches to handling
large user populations.

Other sources have hinted that it may be wise to keep ordinary user
uids and gids away from the 0-1000 range. The firmness of this advice
is inversely proportional to the u/gid, so that this advice may be
meaningless in 100-999, should be noted in 50-99, and obeyed below 50.
(Having said that, we have just this week received UNIRAS 6.2a which
says it requires to use both uid and gid 21149!).

: David Lee Computer Centre :
: University of Durham :
: Phone: +44 91 374 2882 (ddi) South Road :
: Fax: +44 91 374 3741 Durham :
: ARPA: [email protected] U.K. :
: JANET: [email protected] :

Slashdot Nested Groups on Unix

Claus Färber asks: "Is there an easy way to add nested groups (i.e. groups that contain or import user lists from other groups) to Unix account management? While you can manually add all users of one group to the other, it is very hard not to forget to remove or add users to all groups. I already thought of patching NIS modules, providing a PAM module (but will this work with Samba and NFS?) or switching to LDAP (but RFC 2307 does not allow nested groups either...). Has anyone already done this, or are there better ideas?" I've always wondered about this issue as well. Wouldn't extending the /etc/group file to handle nested groups, and the ability to exclude users from groups, be a way of implementing a more finely grained permissions system for Unix?

To understand the advantages of nested groups, I'll use the following example:

Typically, unix groups look like the following:

a: user1, user2, user3
b: user3, user4, user5
c: user6, user7, user8

Now if I want to create a group "d" that is comprised of groups "b" and "c" under most Unices, then you'd add the following line to /etc/groups:

d: user3, user4, user5, user6, user7, user8

Now if I were allowed to nest groups, I could just do:

d: @b, @c

Where the "@" means 'import names from group "b"'.

The advantage of the latter system is that you can add users to group "b" and "c" and not have to maintain the group "d" line as well. Another useful extension would be the exclusion operator, so that if I wanted to remove a specific user from a group (to insure said user isn't included, even if he's a member of an included group) I could do the following:

e: !user1, @a, @b

Instead of manually creating a new list of individual user names:

e: user2, user3, user4, user5, user6

Now you can do something similar to this using NIS and netgroups for large networks, but this feature seems to be particularly useful for the single-machine-large-userbase without the hassle of configuring another service. Would you admins out there find this to be a useful feature? If so, how difficult would it be to modify existing Unix systems to handle these extensions? If not, what reasons can you give as to why future Unix systems should not implement this feature?

Corporate solution

(Score:2)

by CoderDevo (30602) <[email protected]> on Wednesday December 13 2000, @03:59PM (#563660)
(http://slashdot.org/)

If the nested groups under Unix problem needs to be solved for all systems in a corporation, then let me suggest Conrol-SA from BMC Software. It provides one GUI console to manage users and groups for all systems in the enterprise.

Control-SA uses an entity called a Job Code to associate the groups a user needs to be a member of to perform his/her job. These groups can even be on different systems. When a new employee joins the company, you drag and drop the Job Code onto the User. All user accounts for that person are created on all systems they need access to based on the groups to which the Job Code is connected.

In fact, Control-SA even catches and displays changes to user accounts if a system administrator modifies the accounts without using the Control-SA GUI.

I'm sorry for the plug, but I spend all of my time working with this stuff and I love it.

Preprocessor

(Score:4)

by alannon (54117) on Tuesday December 12 2000, @06:30PM (#563665)

Maybe I'm being a little bit naive, but wouldn't it be possible to simply write a preprocessor that followed your rules and spat out a completed /etc/groups file as a result? Then your solution would be portable and would require no new additions to any other systems.

Recommended Links

Softpanorama Recommended

Top articles

Sites

• Group identifier - Wikipedia, the free encyclopedia
• Solaris administration: unix groups -- Oracle
• Guidelines for Using User Names, User IDs, and Group IDs
• Using Unix Groups
• UNIX File Permissions Tutorial -- a brief tutorial from dartmouth.edu
• [Chapter 22] 22.2 Tutorial on File and Directory Permissions
• Users, Groups and Passwords
• 1991 Summary UNIX groups
• SG245962

• GeodSoft How-To Hardening Systems, Users, Groups and Security

  For a server application like a web site where content corresponds to organizational units, NEVER use standard OS system accounts to manage access to application data. Don't even use an account such as OpenBSD's "staff" as an equivalent for employees. If you examine /etc/login.conf you'll see that "staff" is a relatively privileged group. They can login when others cannot and have higher limits on most resources than other groups. OpenBSD's staff group is intended for computer staff, i.e. administrators and backup operators and maybe a webmaster. It's not an equivalent to "employees". If you need such a group, create it.

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019