On Wed, Jan 14, 2009 at 8:00 AM, Jose R. Valverde <jrvalverde@cnb.csic.es> wrote:

From what I remember this had to do with two old time trends.

First you have a professional trend: an ancient system would not be normally
run by one sysadmin (or even the user) as it is now. There would be a data
center with a legion of workers.

You would have the master system manager/administrator (root). In some
cases it might have more than one member or even -e. g. BSD2- a special
group name 'superuser'.

Then a hoard of minions to handle basic tasks (operators) like launching
system backups, allocating resources, changing tapes on user request,
getting printouts and giving them back to users, handling punched cards
on user behalf, running fsck, restarting the system, putting paper on
printers... (users were often not allowed inside the computer room where
expensive equipment was locked).

This (root + operators) would deal with the minimal set of the time, but on
most places you would also have junior sysadmins (to manage delegated system
tasks like rebuilding the kernel), system programmers (to develop system
software and automation scripts), etc.. These would belong to the 'sys' group
which would allow them wider access than 'oper' but less than 'root'. And
then you would have assistants, students, secretaries, etc... all of them
also part of the computer center 'staff' so they could share memos, data, etc..

'guest' should be obvious. Most single users do not need it, but we still use
a 'guest' group for external visitors, short course students, demonstrations,
etc... to distinguish them from normal users -who can do more (and pay for it).
Still, even for home systems, notice how the Mac and Windows still provide by
default a 'guest' account (useful when a relative or friend pays a visit and
you don't want them to use your account nor setup a one-time account either).

Secondly, you have a modularization trend. In principle it might seem sensible
that all system binaries belong to 'root'. And they do on many modern systems.
On second thought -and at the time- it makes more sense to have categories:

Critical system files would belong to 'root' and not be modifiable by anyone.

When you have system programmers adding software, or junior sysadmins installing
user software, you need to give them some privilege. If that is not 'root' which
should it be? The 'bin' group solves the problem. You can think of 'bin' as
'binary installer' (software, manual pages, files...).

Then, you may need a separate group for other, non-public or non-shared files.
This was originally group 'other', and /var/spool or /usr/spool belonged to it.

But then you can go further ahead: some software is special, so why not make a
distinction? Daemons are a prominent case: they have no associated terminal,
so they need to log their messages to a file. Simplest way is to have a
'daemon' group. This was the case for 'netdaemon' and its spawned daemons in
BSD, later inetd, but also LPR, SENDMAIL, UUCP, etc.. Programs in this group
could log messages in a directory owned by 'daemon' and these logs would need
not be visible outside the group.

What confuses you is that taking this to the extreme leads you to use separate
groups and log directories for each daemon as we do now. And even for separate
user programs (e. g. if they need direct access to a hardware device). See
e.g. X11.

But think of it: which is more informative when you see a directory?
Seeing it belongs to 'xyz.nlm' as you do now or to 'xyz.daemon'? In a personal
system where you did yourself or do not care, the first is OK. On a complex
house with lots of hands the second wins. It is like the later division in SV
between 'bin' and 'sbin' to separate security sensitive system binaries.

As for nobody/nogroup... I'd say it's a dilettante game play. Or a matter of
taste. Problem is, once someone users 'nogroup' and expects it, you need to
have both to avoid breaking the odd tool (sigh).

On Tue, 13 Jan 2009 18:59:40 -0600 (CST)
"Jeremy C. Reed" <reed@reedmedia.net> wrote:
> Trying to understand some users and groups that continue to exist on BSD
> systems.
>
> Can someone please point me to references or share examples of historical
> and/or recent uses of the following users and groups?
>
> Also any clarifications of my understandings below would be appreciated.
>
> (My context is BSD. I know some of these may have different old and
> existing uses on other systems.)
>
> daemon user
> I see /var/msgs on NetBSD is owned by daemon. msgs will abort if doing -c
> (cleanup) if not root or daemon user. I guess that is historic. I don't
> see any daemon user usage.
>
> operator user
> I understand that historically, the operator user had logins
> for those doing disk backups (via its login group privileges).
> I understand the operator group, just wondering if any recent uses of
> operator user.
>
> bin user
> Don't know what uses it.
>
> daemon group
> I understand that historically, these are for processes needing less
> privileges than the wheel group. Also historically, programs using
> /var/spool directories were setgid daemon. Anything common other than
> LPD/LPR still use the daemon group?
>
> sys group
> I understand that historically, the sys group was used for access to the
> kernel (/sys?) sources. (I don't know if that was just read or was for
> writing too.) Anyone still use "sys" group? (I guess this is like wsrc
> which sometimes I manually setup and use for writing to src directories.)
>
> bin group
> I understand that historically, used as the group for system binaries, but
> commonly the wheel group is used instead. Some third-party software, like
> OpenOffice.org, install files owned by the bin group.
>
> staff group
> How would this differ from wheel or operators?
> Any recent systems actually have default use of this?
>
> guest group
> Any recent systems actually have default use of this?
>
> nobody group versus nogroup group
> What is the significance of having both of these groups?
>
>
> Thanks!
> _______________________________________________
> TUHS mailing list
> TUHS@minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

--
EMBnet/CNB
Scientific Computing Service
Solving all your computer needs for Scientific
Research.

http://bioportal.cnb.csic.es
http://www.es.embnet.org

_______________________________________________
TUHS mailing list
TUHS@minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs