I am a newbie and am trying to learn OpenBSD. I am currently running OpenBSD 4.5-RELEASE. I have some questions regarding user groups & login class(es). I have listed my questions below. I have summarized my research/findings as "notes" and have put that next to the question.

I would appreciate if you could help me.

When I scan /etc/group, I see a set of default groups in that file. example: staff, users, operators etc.

Question-1:
In what way is the group "staff" different from "users" and "operators"?
Notes: Users in the operator group can mount & unmount. Other groups do not have this privilege.

Question-2:
What special purpose/ task definition associated with each of these groups?
Notes:Tried online man pages available at openbsd.org.
Read login.conf.

Q1: one has a GID of 10, another has a GID of 5, and the other a GID of 20. This is basically what the operating system sees with regard to membership within a 'group'.

Q2: some have specialized uses, OpenBSD seems to like daemon related groups to start with an _, but in general a group is for whatever you make of it. login.conf on my system notes what purposes the login classes & groups serve for: daemon is used by programs, staff has fewer restrictions, authpf deals with authpf, operator can do somethings that others shouldn't: like update /etc/dumpdates when dumping the system. Many programs in the /bin:/usr/bin:/sbin:/usr/sbin directories are owned by root:bin by default. TTY device files are often owned by root or uucp, with groups of dialer or wheel. Commands like write and talk, work by reading and writing to the users TTY device file, a tty group and a simple control of file permissions works wonders (mesg just didles this):

Q3: login.conf describes authentication and resource limits, these can be useful for example, to prevent a daemon from burning so much resources that it denies other processes access to resources (like memory or fork bombs). The manual page describes it more so. Also when you create a user, you specify their default group, which is the GID entry saved in the passwd database.

Q4: When you want too! Although when appropriate would be wiser. Look at login.conf and perhaps, the login source code as well.

Could you please elaborate the best practices that I need to follow when using the said groups and login classes?

(aka) Supplementary questions:
From your explanations, this is what I infer. Please confirm if I understood it right.

a) The purpose of a group is to assemble a set of users and treat them as a block. Such grouping facilitates permission setting, as it can be maintenance intensive to list &/or update rights of each user individually.

b) The purpose definition as to what a group (say US_employess) can and cannot do are special connotations that a sysadmin/owner attaches to that name.

c) The group called "users" does not have any special task association. All users of the system can be part of this group.

d) The groups staff & operators have special task functions/uses. Hence, when I need to add an user to my system, I need not include them into these groups. Said another way, most users who have accounts on my system should not belong to these groups.

e) It is a good idea to not put newbies in the staff group. (The least no. of groups that they are, it is good.)

f) In a corporate environment, the people who are designated to work on backups etc. only should be part of the group called operators. In a home setup, users who are likely to mount & unmount flash drives, cd-roms should belong to this group.

g) Login class is a super governor that sets resource limits as detailed in login.conf.

Thanks again for taking the time to explain things to a newbie. I appreciate it.

Sounds close enough, but on g) I would have to say that the kernel is the almighty governor of resource limits, with the hardware being the HBIC.

Traditional UNIX file permissions are basically a limited no frills implementation of Access Control Lists, still works ok today but modern ACLs are better in more complex situations. A unix permission mask is basically an ACL restricted to 3 entries: owning user, owning group, and everyone else; with 3 permissions available for each entry: read, write, and exec. (Contrast to some of the TOPS family). The name means nothing, its just an identifier: the system deals with numbers (*UIDs and *GIDs), so you can basically name users & groups whatever your OS allows. (For example, BSD allows me to use 'Terry' instead of GNU/Linux distros forced 'terry'; but its the numbers that count on access control)

Setting the login class can limit the harm the user or program can cause, so for example the login class _mysql that I created, it gives the invocator less stingent resource limits then the typical daemon class - yet it still has limits on how much it can consume.

Code:

su -c loginclass username -c 'commands here'

can run a 'commands here' under username, with the specified login class instead of the users normal one - so for example, a program can be run as demigod for the file perms but a different login class used to control resource limits.

The system provides a few things like operator that are useful, but utilizing the permissions and login systems, you can create arbitrary concoctions of your own, as they are needed. A worthless example might be allowing junior developers to edit and build source files in a shared project directory, but only allowing senior developers to commit code to the local version control system.

edit: you might also want to look at a program called chflags, in the system manual