DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD General

OpenBSD General Other questions regarding OpenBSD which do not fit in any of the categories below.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 8th October 2009
Greg_Morgan Greg_Morgan is offline
Port Guard
 
Join Date: May 2009
Posts: 13
Thanked 0 Times in 0 Posts
Question Pre-installed Groups: What are they for?

Hi.

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.

Sample query in man.
cgi-bin/man.cgi?query=operator&apropos=0&sektion=1&manpath =OpenBSD+Current&arch=i386&format=html

(As I am new to this forum, the forum program does not allow me to put the actual url. Hence, please run the above query at openbsd.org)


Question-3:
What is the difference between the login classes: default & staff?
Notes:
Assumption: Logins in the "staff" class has special privileges.

Release 4.6 has special changes in this (i.e.)
Make the install scripts add the default user to the 'staff' login class..


Question-4:
When I create a login, the de-facto class is "default". When should I use
the login class called "staff"?



I look forward to hearing from you.

Thanks.
-gm

Last edited by Greg_Morgan; 8th October 2009 at 02:27 AM. Reason: Easier reading.
Reply With Quote
  #2   (View Single Post)  
Old 8th October 2009
TerryP's Avatar
TerryP TerryP is offline
Arp Constable
 
Join Date: May 2008
Location: USofA
Posts: 1,547
Thanked 112 Times in 104 Posts
Default

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

Code:
Terry@vectra$ ls -l $(tty)
crw--w----  1 Terry  tty    5,   0 Oct  8 02:55 /dev/ttyp0


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.
__________________
My Journal

Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest ``foo'' someone someday shall type ``supercalifragilisticexpialidocious''.
Reply With Quote
  #3   (View Single Post)  
Old 8th October 2009
Greg_Morgan Greg_Morgan is offline
Port Guard
 
Join Date: May 2009
Posts: 13
Thanked 0 Times in 0 Posts
Default

TerryP,

Thanks for your detailed reply.

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.

Regards,
gm
Reply With Quote
  #4   (View Single Post)  
Old 8th October 2009
TerryP's Avatar
TerryP TerryP is offline
Arp Constable
 
Join Date: May 2008
Location: USofA
Posts: 1,547
Thanked 112 Times in 104 Posts
Default

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
__________________
My Journal

Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest ``foo'' someone someday shall type ``supercalifragilisticexpialidocious''.
Reply With Quote
  #5   (View Single Post)  
Old 9th October 2009
Greg_Morgan Greg_Morgan is offline
Port Guard
 
Join Date: May 2009
Posts: 13
Thanked 0 Times in 0 Posts
Default

Thanks TerryP.
Reply With Quote
  #6   (View Single Post)  
Old 11th October 2009
ocicat ocicat is offline
Administrator
 
Join Date: Apr 2008
Posts: 2,879
Thanked 190 Times in 160 Posts
Default

Moving thread to general subforum.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Various Groups -- Information JMJ_coder General software and network 3 20th December 2008 04:35 AM
groups.google.com down? jb_daefo Off-Topic 2 23rd September 2008 03:37 AM
ezjail /usr/home users and groups question neurosis FreeBSD Security 7 8th September 2008 08:40 PM
Installed 4.3 & No GUI warriors OpenBSD General 24 14th August 2008 11:28 AM
Has anyone installed mod_perl erehwon OpenBSD Packages and Ports 5 23rd June 2008 08:11 PM


All times are GMT. The time now is 10:05 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick