Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Unix Groups Administration

News Authentication Recommended Links The /etc/group file Unix permissions model UID policy
System Groups Primary Group Wheel Group User Private Groups Managing user accounts in Perl Solaris RBAC
Admin Horror Stories System Accounts Unix History  Humor Humor Etc

Unix groups as we know them were invented by BSD. 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 but the implementation  was subject to three serious limitations:

As a result it must be openly stated that groups membership in Unix usually is taken "as is" and is not customaized or enhanced by system administrators. In other words sysadmin usually do not engage is new group definitions,. At  best, they define one or two unique groups that contain some users that are important in a particular enterprise (and often creating security vulnerability if they use such a group as a common primary group for user accounts). 

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, 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).

For historical reasons there are two types of the groups in Unix: primary group (a group that is mentioned in /etc/passwd for one or several users) and all the rest.

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 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.

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. Shared primary group 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 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 (once a day) 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 and non-system groups. Important non-system groups are:

Account Administration

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.

User Accounts

User accounts can be added, modified, or deleted using command-line utilities or by using the admintool(1M) command. Use of the admintool command reduces or eliminates the possible introduction of typos and other errors that might affect all the user accounts.

However, the admintool command requires a graphical interface and is more time consuming than using the command-line utilities manually. These command-line utilities are as follows:

Both the admintool command and the command-line utilities are described in this chapter.

Creating an Account Using the admintool Command

When the admintool command is started, the Users window is displayed. To display the Add User window, select Add from the Edit pull-down menu. The Add User window, consists of three sections: User Identity, Account Security, and Home Directory.

The User Identity section provides the information that needs to be defined to add a user account. All this information is stored in the /etc/passwd file, except secondary groups information, which is stored in the /etc/group file. Table 3.1 lists the fields of the User Identity section.

Table 3.1 User identity Fields of the admintool: Add User Window

Field Description
User Name A unique user account name consisting of a maximum of eight upper- and lowercase letters and/or numbers.
User ID The UID associated with the user account. A unique number, typically between 1000 and 60000. The next available number starting at 1000 is provided automatically.
Primary Group The group to which the user should be assigned. By default, 10 (staff) is provided. Any specified group must exist before members can be added.
Secondary Groups Additional groups (separated by commas) to which the user should be assigned. Specified groups must exist before members can be added.
Comment Any text that should be placed in the /etc/passwd Comment field.
Login Shell The Bourne (default), C, or Korn shell can be selected. Another shell can be specified by selecting Other from the pull-down menu and entering the name of the shell in the field.


The Account Security section provides the information used to determine how the password should be defined and to set up password aging. All this information is stored in the /etc/shadow file. Table 3.2 lists the fields of the Account Security section.

Table 3.2 Account Security Fields of the admintool: Add User Window

Field Description
Password The choices are Cleared until first login, Account is locked, No password—setuid only, and Normal Password.
Min Change Minimum days required between password changes.
Max Change Maximum days a password is valid.
Max Inactive Maximum number of days account can be inactive before password must be changed.
Expiration Date Date account expires.
Warning Number of days user is warned before password expires.


 

The Home Directory section is used to define the home directory of the account and to create it if necessary. This path is stored in the /etc/passwd file. The appropriate initialization files are created in the home directory based on the type of login shell selected.

Modifying an Account Using the admintool Command

To modify a user account, start the admintool command if it is not already active. Display the Users window by selecting Users from the Browse pull-down menu.

Click the desired account entry and then select Modify from the Edit pull-down menu. The Modify User window is displayed. Change the fields as appropriate and click Apply to save the changes.

Deleting an Account Using the admintool Command

To delete a user account, start the admintool command if it is not already active. Display the Users window.

Click the desired account and then select Delete from the Edit pull-down menu. In the Warning window, select Delete to delete the user account.

CAUTION

Because using the admintool command makes creating, modifying, and deleting user accounts very easy and intuitive, Exam 310-014 concentrates on using the useradd, usermod, and userdel commands for administering user accounts.

Creating an Account Using the useradd Command

The useradd(1M) command provides a quick method to add a new user account. At a minimum, the account name must be specified as a command-line argument. Table 3.3 lists the command-line arguments supported by the useradd command.

Table 3.3 Command-Line Arguments for the useradd Command

Argument Description
account Specifies the name of the new user account (required).
-A authorizations Specifies one or more authorizations.
-b base Defines a base directory. If a home directory (-d) is not specified, the account name is added to base and used as the home directory.
-c comment Specifies a comment that is placed in the comment (gcos) field of the /etc/passwd file.
-d directory Defines the home directory of the account.
-e date Specifies the expiration date for the account. After the specified date, the account is disabled.
-f days Specifies the maximum number of days the account can be inactive before it is disabled.
-g group Defines the GID or name of an existing group that will be the primary group for the user account.
-G group Defines a GID or name of an existing group that will be a secondary group for the user account.
-k template_dir Specifies the directory that contains a template (default) profile used for the user account.
-m Creates the home directory if it doesn't exists. The home directory is defined by -b and account name or -d.
-o Allows an existing UID to be specified. That is, it allows an account to be created with a duplicate UID (see -u).
-p profiles Specifies one or more execution profiles.
-R roles Specifies one or more user roles.
-s shell Specifies the login shell; default is the Bourne Shell (/bin/sh).
-u uid Specifies the UID of the user account. It must be a decimal integer. If not specified, the next highest available UID is assigned.


 

The following example shows how to create a user account using the useradd command:

# useradd -d /export/home/user1 -m -g other -u 1050 user1
6 blocks
#

This command creates the user1 user account, assigns it UID 1050, makes it a member of group other and creates its home directory /export/home/user1.

To make life a little easier, the useradd command also supports the -D command-line argument, which allows default values to be assigned to authorizations (-A), base directory (-b), group (-g), expiration date (-e), maximum inactivity (-f), execution profile (-P), and role (-R). Subsequent uses of the useradd command will use these default values if they are not specified. For example, the following command can be used to assign a default base directory and default group. Whenever defaults are assigned or changed, the new defaults are listed:

# useradd -D -b /export/home -g other

group=other,1 project=,3 basedir=/export/home 
skel=/etc/skel shell=/bin/sh inactive=0 
expire= auths= profiles= roles= 
#
# useradd -m -u 1051 user2
6 blocks
#

Because a default base and group were defined, the user2 account is a member of the other group and has a home directory of /export/home/user2.

NOTE

User accounts created with the useradd command do not have a password. These accounts are locked and cannot be used until a password is set for the account using the passwd(1) command.

Modifying an Account Using the usermod Command

The usermod(1M) command is used to modify an existing user account. The command-line arguments are identical to the useradd command-line arguments with the following exceptions:

Keep in mind that if the account name is changed, the name of the home directory does not change unless the -d and -m command-line arguments are used. The following example shows the usermod command changing the name of the user1 account to user3.

# ls -l
total 22
drwx------  2 root   root    8192 Jan 13 21:05 lost+found
drwxr-x---  2 user3  other    512 Mar 31 13:23 user1
drwxr-x---  2 user2  other    512 Mar 31 13:45 user2
#
# usermod -luser3 -d /export/home/user3 -m user1
6 blocks
#
# ls -l
total 22
drwx------  2 root   root    8192 Jan 13 21:05 lost+found
drwxr-x---  2 user2  other    512 Mar 31 13:45 user2
drwxr-x---  2 user3  other    512 Mar 31 13:23 user3
#

Deleting an Account Using the userdel Command

The userdel(1M) command is used to delete a user account. The user account is specified as a command-line argument. Only one other command-line argument is supported. This is -r, which is used to remove the home directory. The following shows deleting the user3 account:

# userdel -r user3
#

Group Accounts

Group accounts can be added, modified, or deleted using command-line utilities or by using the admintool(1M) command. Use of the admintool command reduces or eliminates the possible introduction of typos and other errors that might affect all the group accounts.

However, the admintool command requires a graphical interface and is more time consuming than using the command-line utilities manually. These command-line utilities are as follows:

Both the admintool command and the command-line utilities are described in the following sections.

Creating a Group Using the admintool Command

To create a group account, start the admintool command if it is not already active. Display the Groups window by selecting Groups from the Browse pull-down menu.

Then, display the Add Group window by selecting Add from the Edit pull-down menu.

Enter a unique group name in the Group Name field. Use the next available GID number or enter a unique GID in the Group ID field. In the Members List field, enter one or more user account names separated by commas. Using the mouse, click OK. The new group is displayed in the Groups window.

Modifying a Group Using the admintool Command

To modify a group account, display the Group window. Click the account you want to modify, and then select Modify from the Edit menu. Change the fields in the Modify Group window, and click Apply to save the changes.

Deleting a Group Using the admintool Command

To delete a group account, display the Groups window, and then select the account you want to delete. Select Delete from the Edit menu. A Warning window displays that lists the group. Click Delete.

CAUTION

Because using the admintool command makes creating, modifying, and deleting group accounts very easy and intuitive, Exam 310-014 concentrates on using the groupadd, groupmod, and groupdel commands for administering group accounts.

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
#

Password Administration

Password administration involves setting parameters to control password aging, changing a user's password as needed, and possibly locking a user account to prevent use.

Password Aging

The parameters of the /etc/shadow file determine the password aging policy. These are set through the Account Security fields of the admintool command's Add or Modify User Account window. This includes how long a password is valid (Max Change), how often it can be changed (Min Change), and how long an account can be inactive before the password must be changed (Max Inactive). These parameters enforce a policy for protecting the integrity of passwords.

Note that of these three password-aging parameters, only Max Inactive can be specified using the useradd command and modified using the usermod command.

Password Requirements

Unless specified by a superuser account such as root, passwords must meet the following requirements:

CAUTION

Passwords can be any length, but only the first eight characters are significant. For example, a password can be defined as 25administration but 25admini is actually used to log into the system.

Keep in mind that these requirements do not apply when root or some other superuser account defines its own password or the password of another user account.

Changing Passwords Using the admintool Command

To change the password of a user account, start the admintool command if it is not already active. Display the Users window by selecting Users from the Browse pull-down menu.

The user account can be selected in two ways: by double-clicking the account entry or by clicking the account entry to highlight it and then selecting Modify from the Edit pull-down menu. Using either method, the Modify User window is displayed.

To modify the account password, position the mouse cursor over the Password field and hold down the left button. Then, move the mouse cursor over the Normal Password item and release the mouse button.

Enter the same password for both the Enter Password and the Verify Password fields. Asterisks are displayed in place of each character entered. Using the mouse, click OK. To save the password, click OK in the Modify User window.

Changing Passwords using the passwd Command

Other than using the admintool command, the passwd(1) command is the only other way to change the password for a user account. When used without any command-line arguments, the passwd command changes the password of the current user account. The following code shows how to change the password for the currently logged in user (dla):

$ passwd
passwd: Changing password for dla
Enter login password: 
New password: 
Re-enter new password: 
passwd (SYSTEM): passwd successfully changed for dla
$

Note that the current password must be entered before a new password can be specified. When a superuser account, such as root, uses the passwd command, the current password is not required.

A variety of command-line arguments are provided to support changing passwords. Table 3.4 lists the more significant command-line arguments.

Table 3.4 Selected Command-Line Arguments for the passwd Command

Argument Description
account Specifies the name of the user account for which the password will be changed.
-as Lists password attributes for all user accounts (displays LK for locked, PS for password, and so on).
-d Deletes the password for the specified account.
-l Locks the specified account so it cannot be accessed.


 

A superuser account can change the password for another user account. The user account is specified as a command-line argument. The following shows the superuser changing the password for the dla account:

# passwd dla
New password: 
Re-enter new password: 
passwd (SYSTEM): passwd successfully changed for dla
#

Locking a User Account Using the admintool Command

An account can be locked to prevent it from being used. In the admintool's Users window, select the account you want to lock. Select Modify from the Edit menu. In the Modify User window, choose the Account Is Locked item, save the change, and click OK.

Administrative System Files

Three administrative system files are used to define and manage user and group accounts:

/etc/passwd

The /etc/passwd file is an ASCII file that is used to define user accounts on the local system. Each line represents a user account and consists of seven colon-delimited fields. Table 3.5 lists the fields of an entry in the /etc/passwd file.

Table 3.5 /etc/passwd Fields

Field Purpose
user name The unique name assigned to the user account.
password In earlier versions of Unix, the password field contained the encrypted account password. For security reasons, the passwords have been moved to the /etc/shadow file. The letter "x" is typically placed in this field to indicate that the password is in /etc/shadow.
UID A unique numeric identification assigned to the user account. Any processes or files created by the user account will be owned by this UID. The system administrator account, root, is assigned the UID of 0. This is the UID of a superuser account. System maintenance accounts are usually assigned a UID of less than 100, whereas user accounts typically start at 1001.
GID The numeric identification of the default group that the user account has been assigned to as a member. Groups are defined in the /etc/group file.
comment field Information about the owner of the user account, such as real name, phone number, mailing address, and so on. An ampersand in this field is interpreted as the contents of the username field.
home directory The full path to the directory where the user is initially located after logging in.
login shell The full pathname of the initial shell used as a command inter-preter. If left empty, the default is /usr/bin/sh.


 

The following listing shows the default contents of a Solaris 9 /etc/password file:

root:x:0:1:Super-User:/:/sbin/sh
daemon:x:1:1::/:
bin:x:2:2::/usr/bin:
sys:x:3:3::/:
adm:x:4:4:Admin:/var/adm:
lp:x:71:8:Line Printer Admin:/usr/spool/lp:
uucp:x:5:5:uucp Admin:/usr/lib/uucp:
nuucp:x:9:9:uucp Admin:/var/spool/uucppublic:/usr/lib/uucp/uucico
smmsp:x:25:25:SendMail Message Submission Program:/:
listen:x:37:4:Network Admin:/usr/net/nls:
nobody:x:60001:60001:Nobody:/:
noaccess:x:60002:60002:No Access User:/:
nobody4:x:65534:65534:SunOS 4.x Nobody:/:

/etc/shadow

The /etc/shadow file is an ASCII file that is used to store passwords for local user accounts along with any password restrictions or aging. Access is restricted to superusers to protect the passwords. Each line represents the password of a user account and consists of nine colon-delimited fields. Table 3.6 lists the fields of an entry in the /etc/shadow file.

The /etc/shadow file should always be protected from unauthorized access or copying because it contains all user passwords for the system. Although the passwords are stored in encrypted form, it is still possible to find passwords using specialized software.

Table 3.6 /etc/shadow Fields

Field Purpose
User account Used to relate the /etc/shadow entry to a user account defined in the /etc/passwd file.
password A 13-character encrypted password for the associated user account. If the field contains NP, this account is used only to own processes or files (setuid) and cannot be used to log in to the system. If the field contains *LK*, the account is locked and cannot be used to access the system. If the field is empty, no password exists, and the user is forced to enter a password the first time the account is used.
last changed The number of days between January 1, 1970, and the last date the password was changed.
minimum The minimum number of days required to pass before the user is allowed to change the password again.
maximum The maximum number of days the password is valid.
warning The number of days the user is warned before the password expires.
inactivity The number of days account can be inactive before the password must be changed.
expiration The number of days between January 1, 1970, and the date on which the account expires.
flag Reserved for future use.


 

The following listing shows the guest entry from a Solaris 9 /etc/shadow file that uses all the fields except flag:

guest:on7GbE18yYAek:10688:5:30:5:20:10844:

/etc/group

The /etc/group file is an ASCII file that is used to store information about groups on the local system. Each line represents a group and consists of four colon-delimited fields. Table 3.7 lists the fields of an entry in the /etc/group file.

Table 3.7 /etc/group Fields

Field Purpose
group name The unique name of the group.
password The password associated with the group. If a password is present, the newgrp(1) command prompts users to enter it.
GID The unique numeric group identification.
users A comma-separated list of user accounts that belong to the group.


 

The following listing shows the default contents of a Solaris 9 /etc/group file:

root::0:root
other::1:
bin::2:root,bin,daemon
sys::3:root,bin,sys,adm
adm::4:root,adm,daemon
uucp::5:root,uucp
mail::6:root
tty::7:root,adm
lp::8:root,lp,adm
nuucp::9:root,nuucp
staff::10:
daemon::12:root,daemon
sysadmin::14:
smmsp::25:smmsp
nobody::60001:
noaccess::60002:
nogroup::65534:

User Account Initialization Files

Several initialization (or startup) files are associated with each user account home directory. These files are used to specify commands to be executed when the associated event occurs. Depending on the login shell being used (Bourne Shell, C Shell, or Korn Shell), there might be a login initialization file, a shell startup file, or a logout file. Table 3.8 lists the various initialization files.

Table 3.8 Initialization Files

File Bourne (sh) C (csh) Korn (ksh)
Login initialization file .profile .login .profile
Shell startup initialization file N/A .cshrc user-defined
Logout file N/A .logout N/A


 

Commands in the login initialization file are executed when the user logs in. All three common shells provide a login initialization file. Commands in the shell startup file are executed whenever the logged-in user starts a shell. Both csh and ksh provide this capability. The ENV parameter is used to define the name of the ksh shell startup initialization file. Only csh provides a file for automatic execution of commands when a user logs out.

CAUTION

It is important to know the names of the initialization files and their uses, not only for the Bourne shell, but also the C and Korn shells.

The System Profile

For user accounts that use sh (Bourne shell) or ksh as a login shell, commands in the system profile are executed before the user's login initialization file. This file is named /etc/profile and, when executed, sets a default terminal type (TERM) and then calls umask(1) to set the default file permission mask to 022. If the user's home directory does not include a file by the name of .hushlogin, the user's storage quota is displayed using quot(1M), the message of the day (if any) is displayed, and a notification message is displayed if new email has arrived for the user.

The following listing shows the default contents of /etc/profile for a Solaris 9 system:

#ident "@(#)profile  1.19  01/03/13 SMI"  /* SVr4.0 1.3  */
# The profile that all logins get before using their own .profile.

trap "" 2 3
export LOGNAME PATH
if [ "$TERM" = "" ]
then
    if /bin/i386
    then
        TERM=sun-color
    else
        TERM=sun
    fi
    export TERM
fi
#    Login and -su shells get /etc/profile services.
#    -rsh is given its environment in its .profile.
case "$0" in
-sh | -ksh | -jsh | -bash)
    if [ ! -f .hushlogin ]
    then
        /usr/sbin/quota
        #    Allow the user to break the Message-Of-The-Day only.
        trap "trap '' 2" 2
        /bin/cat -s /etc/motd
        trap "" 2
        /bin/mail -E
        case $? in
        0)
            echo "You have new mail."
            ;;
        2)
            echo "You have mail."
            ;;
        esac
    fi
esac
umask 022
trap 2 3

Initialization File Templates

When a user account is created and a home directory specified, part of setting up the user account is to copy the appropriate default initialization files to the user's home directory. These initial files or templates are stored in the /etc/skel directory.

For user accounts that use sh or ksh as the login shell, the /etc/skel/local.profile file is copied to the .profile file in the user's home directory. The following listing shows the default contents of the /etc/skel/local.profile file:

# Copyright (c) 2001 by Sun Microsystems, Inc.
# All rights reserved.
#
# ident "@(#)local.profile   1.10  01/06/23 SMI"
stty istrip
PATH=/usr/bin:/usr/ucb:/etc:.
export PATH
#

For user accounts that use csh as the login shell, the /etc/skel/local.login file is copied to the .login file in the user's home directory. The following listing shows the default contents of the /etc/skel/local.login file:

# Copyright (c) 2001 by Sun Microsystems, Inc.
# All rights reserved.
#
# ident "@(#)local.login    1.7   01/06/23 SMI"
stty -istrip
# setenv TERM ´tset -Q -´

In addition, for user accounts that use csh as the login shell, the /etc/skel/local.cshrc file is copied to the .cshrc file in the user's home directory. The following listing shows the default contents of the /etc/skel/local.cshrc file:

#ident "@(#)local.cshrc    1.2   00/05/01 SMI"
umask 022
set path=(/bin /usr/bin /usr/ucb /etc .)
if ( $?prompt ) then
    set history=32
endif

Also in the /etc/skel directory is a simple .profile that can also be used as a default:

#    This is the default standard profile provided to a user.
#    They are expected to edit it to meet their own needs.

MAIL=/usr/mail/${LOGNAME:?}

When an account is created using the admintool command, the appropriate /etc/skel file is copied to the home directory of the user account based on the selected login shell (that is, .profile for Bourne and Korn shells, .cshrc for C shell, and so on). However when the useradd command is used, all the /etc/skel files (.profile, local.cshrc, local.login, and local.profile) are copied to the home directory regardless of the selected shell. In this case, the appropriate file(s) (based on type of shell) must be manually configured.

Customizing the User Environment

The initialization file templates can be modified to provide a custom environment for new user accounts. In addition, the system profile (/etc/profile) can be modified to customize the environment for all users during login initialization.

CAUTION

Keep in mind that the system profile, /etc/profile, is executed before the user's profile. This provides the ability to control and restrict the user environment before the user has an opportunity to make any modifications.

To customize individual user accounts, the initialization files in the user's home directories can be modified. For the most part, this will consist of adding commands to be automatically executed or defining shell parameters.

Defining Shell Variables in .profile

Variables defined and exported in the .profile become part of the user's environment. These variables are available to programs and shells executed by the user.

A common shell variable defined in the .profile is LPDEST, which is used to specify a default printer. To define HPLaser as the default printer, include the following in the .profile for a user account:

LPDEST=HPLaser
export LPDEST

An alternative way is to specify both commands on the same line and separate the commands with a semicolon, as shown in the following:

LPDEST=HPLaser; export LPDEST

A similar syntax can be used for a user account that uses the Korn shell as a login shell. ksh also supports the following variation:

export LPDEST=HPLaser

Although defining variables for csh user accounts is not a certification requirement, the syntax for two csh methods of defining variables is shown in the following listing:

set LPDEST=HPlaser
setenv LPDEST HPlaser

NOTE

Changes made to the user's login initialization file do not take effect until the user logs in again, or until the .profile is executed by preceding it with a dot separated by a space. This executes the .profile and makes it part of the current environment.

Sourcing .profile

For user accounts that use the Solaris Common Desktop Environment (CDE), the /usr/dt/bin/Xsession command that starts the desktop can be configured to read and process the .login (csh) or .profile (sh and ksh) login initialization file in the user's home directory as part of the startup process.

The first user-specific file that Xsession calls is the .dtprofile file, located in the user's home directory. The last line of the default .dtprofile file is as follows:

DTSOURCEPROFILE=true

This will cause the .login or .profile file to be executed (or sourced) automatically. To change this default behavior and prevent the login initialization file from being sourced, change true to false.

Summary

User accounts are created using admintool or the useradd commands. Account information is stored in the /etc/passwd file. The /etc/shadow file is used to store user account passwords.

Groups are created using admintool or the groupadd commands. Group information and passwords are stored in the /etc/group file.

Initialization files are associated with each type of shell (Bourne, C, and Korn). These initialization files can be used to set up the environment before the user has access to the system, when each shell is created, or when the user exits the system. Initialization file templates are available in /etc/skel to provide a starting point for creating custom initialization files. The system profile (/etc/profile) is executed before any user account initialization files.

Top Visited
 Switchboard
Latest
Past week
Past month

Old News ;-)

[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.

Slashdot Access Control Lists In Linux Filesystems

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.

Note to slashdot maintainers: PLEASE make the damn text box for typing comments into bigger! The one currently provided on the web form makes typing long comments especially painful. And allowing the CODE HTML tag would be nice too.

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:

Other groups which have no associated user:

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.

[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:

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   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

 

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

************* Majordomo archive: End of Message ********************

 

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

  

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

Google matched content

Softpanorama Recommended

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

Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

 You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

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: October 14, 2011