[TUHS] historical users and groups

[TUHS] historical users and groups

[Jeremy C. Reed]

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] historical users and groups

[Jose R. Valverde]

[TUHS] historical users and groups

[Jason Stevens]

I would recommend the book "The Cuckoo's egg" for a 'feel' of what the old
multi user BSD boxes were like..

http://en.wikipedia.org/wiki/The_Cuckoo's_Egg_(book)

Clifford does go a bit into the administrative roles, and of course tracking
back a SYSV influenced hacker...
It was quite an interesting read when I was a kid, and it still holds up.

Naturally SIMH can run the 4.2BSD that they were running back then... If you
are on windows I've pre-packaged
it here:
http://downloads.sourceforge.net/bsd42/BSD4.2-For-Windows_v0.1a_SIMH-3.7-3.exe?modtime=1189324059&big_mirror=0


Some additional links:
http://www.amazon.com/Cuckoos-Egg-Tracking-Computer-Espionage/dp/0743411463

http://www.ci.ulsa.mx/~elinos/docencia/herseg/cuckoo_egg.pdf



On Wed, Jan 14, 2009 at 8:00 AM, Jose R. Valverde <jrvalverde at 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 at 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 at 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 at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20090115/75bf7719/attachment.html>

[TUHS] historical users and groups

[Angus Robinson]

An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20090116/b2824e03/attachment.html>

[TUHS] historical users and groups

[Jose R. Valverde]

A bit of digging brought out the following snippet from 4.3BSD System
Manager Manual:

     System security  changes  require  adding  several  new
``well-known''  groups  to  /etc/group.  The groups that are
needed by the system as distributed are:

...

Only users in the ``wheel'' group are  permitted  to  su  to
``root''.    Most   programs   that  manage  directories  in
/usr/spool now run set-group-id to ``daemon'' so that  users
cannot  directly  access the files in the spool directories.
The special files that access kernel memory,  /dev/kmem  and
/dev/mem,  are  made readable only by group ``kmem''.  Stan-
dard system programs that require this access are made  set-
group-id  to  that  group.  The group ``sys'' is intended to
control access to system sources, and other  sources  belong
to  group ``staff.'' Rather than make user's terminals writ-
able by all users, they are now placed in group ``tty''  and
made only group writable.  Programs that should legitimately
have access to write on user's terminals such  as  talk  and
write  now  run  set-group-id  to ``tty''.  The ``operator''
group controls access to disks.  By default, disks are read-
able  by group ``operator'', so that programs such as df can
access the file system information without being set-user-id
to ``root''.

     Several new users have also been added to the group  of
``well-known'' users in /etc/passwd.  The current list is:

...

The ``daemon'' user is used for daemon processes that do not
need  root  privileges.  The ``operator'' user-id is used as
an account for dumpers so that they can log in without  hav-
ing  the root password.  By placing them in the ``operator''
group, they can get read access to the disks.  The  ``uucp''
login has existed long before 4.3BSD, and is noted here just
to provide a common user-id.  The password entry  ``nobody''
has been added to specify the user with least privilege.
 


So my previous recollections were not totally correct. Sorry. I guess as
one grows older memory starts to fail. As for today's usefulness... if 
you google each user/group up you'll see they still are meaningful in
many setups.

				j
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20090114/bf910891/attachment.sig>

[TUHS] historical users and groups

[Tim Bradshaw]

On 14 Jan 2009, at 00:59, Jeremy C. Reed wrote:

> staff group
> How would this differ from wheel or operators?
> Any recent systems actually have default use of this?

My memory (from BSD 4.2 / 4/3 systems, I didn't use anything older  
other than transiently) is that staff was for, well, staff: real  
permanent staff, as opposed to guests or students.

Wheel was people who could su, and I think that su knew about the  
wheel group.  Or maybe it just knew about GID 0?  Was wheel always GID  
0?  I have an unreliable memory that it was wheel because it was  
round, like 0.

However This was all lore passed down from people who ran the systems  
before me (other than the su thing, I am pretty sure that I looked at  
source for (some version of) su and it did indeed know about some  
special group) and I don't know where they got it from.

--tim

[TUHS] historical users and groups

[John Cowan]

Tim Bradshaw scripsit:

> Wheel was people who could su, and I think that su knew about the  
> wheel group.  Or maybe it just knew about GID 0?  Was wheel always GID  
> 0?  I have an unreliable memory that it was wheel because it was  
> round, like 0.

Interesting etymology, but like most such things, false.  Thus spake
the Jargon File:

wheel: n.

    [from slang "big wheel" for a powerful person] A person who has an
    active wheel bit. "We need to find a wheel to unwedge the hung tape
    drives." (See wedged, sense 1.) The traditional name of security
    group zero in BSD (to which the major system-internal users like root
    belong) is "wheel". Some vendors have expanded on this usage,
    modifying Unix so that only members of group "wheel" can go root.

wheel bit: n.

    A privilege bit that allows the possessor to perform some restricted
    operation on a timesharing system, such as read or write any file
    on the system regardless of protections, change or look at any
    address in the running monitor, crash or reload the system, and
    kill or create jobs and user accounts. The term was invented on
    the TENEX operating system, and carried over to TOPS-20, XEROX-IFS,
    and others. The state of being in a privileged logon is sometimes
    called wheel mode. This term entered the Unix culture from TWENEX
    in the mid-1980s and has been gaining popularity there (esp. at
    university sites). See also root.

wheel wars: n.

    [Stanford University] A period in larval stage during which student
    hackers hassle each other by attempting to log each other out of
    the system, delete each other's files, and otherwise wreak havoc,
    usually at the expense of the lesser users.

-- 
My corporate data's a mess!                     John Cowan
It's all semi-structured, no less.              http://www.ccil.org/~cowan
    But I'll be carefree                        cowan at ccil.org
    Using XSLT
On an XML DBMS.

[TUHS] historical users and groups

[Robert Harker]

My knowledge comes from my early days at Sun in 84-85 as a rock-n-roll roadie 
turned into a UNIX sysadmin.  It was passed to me as I was learning how to 
take care of trade show Sun Workstations.  So take it with a grain of salt.

> daemon user

daemon was for daemon processes that ran in the background but did not want to 
run as root.  I believe it was used by inetd when it spawned a process but an 
not sure.  It was also used by sendmail when it gave up its SUID root privileges.

> operator user

operator was a normal user that had privilege to read the raw file systems 
through group membership.  Sysadmins who did backups would also be a member of 
this group.  The group I recall in the early days was "kmem" although now 
there is a separate group "disk".

> bin user

A user to go with group bin.  Typically would be the "proper" owner of all the 
binaries and libraries on a system.  It has lingered on for far to long 
because, IMHO, the vendors had no clue as to why everything was owned by bin 
and just kept it that way since "thats the way it's always been".

> bin group

I was told that group bin came from UCB to allow semi-trusted staff to replace 
binaries in the file system without giving them the root password.

> staff group

My recollection is that staff was for group read/write permissions for home 
directories, separate from group wheel which granted extra privileges

> nobody group versus nogroup group

The nobody group was a group to go with the nobody user introduced with NFS.
nogroup may have been someone's attempt to make the name more obvious, or it 
may have been for non-privileged account.  But the second case weakens the 
protection of a non-privileged account