From w.f.j.mueller at gsi.de Mon Jan 5 03:49:02 2009 From: w.f.j.mueller at gsi.de (Walter F. Mueller) Date: Sun, 04 Jan 2009 18:49:02 +0100 Subject: [pups] 2.11BSD Patch 446+447; fixes for ulrem,umount,tar,tcsh,ps,vmstat,apropos,pstat,rk Message-ID: <4960F68E.1010507@gsi.de> A note to all 2.11bsd users: Over the past 2 years several bug fixes for 2.11BSD accumulated, and over xmas break I finally found the time to communicate them to Steven Schultz. Steven was so kind to package them into two new patch files 446 issued December 27, 2008 447 issued December 31, 2008 Together, the patches address the following points - ulrem.s: the unsigned long modulo operator (%) was broken in libkern - umount: returned inverted exit codes (1 for success, 0 for failure) - tar: core dumped when a whole /usr tree was archived - tcsh: the time buildin function printed some erroneous or zero statistics - ps: core dumped when '-t' option was used with no further argument - apropos: core dumped when 2 or more arguments were given - vmstat: wrong normalization for some fields - several issues around the rk disk driver - no rk root attach function - no rk BOOTDEV support - incorrect UCB_METER code (vmstat/iostat never showed any rk activity) - autoconfig left the RK11 controller in an error state - pstat: added additional options to access more kernel data structures - new -c option, dumping the coremap - new -m option, dumping the ub_map (UNIBUS map) - new -b option, dumping the buffer pool table - change -s output, gives now full table dump - adapt the info's displayed by -T - some documentation corrections (vmstat, pstat, tcsh) Note: In case you wonder, as I did, why 211BSD survived 20 years with a broken unsigned long % operator: - only the non-FPP libkern implementation was affected - the kernel simply doesn't have any unsigned long modulo's :) - apparently only standalone mkfs after patch 434 was compromised For the full story of all the above consult the header of the patch files. The patch files are available from moe.2bsd.com and ftp.wx.gd-ais.com. Note, that Steven changed the packaging some time ago, the patches are now packed in bzip'ed tarballs in groups of ten patches. So you'll have to look into ftp://moe.2bsd.com/pub/2.11BSD/440-447.tar.bz2 ftp://ftp.wx.gd-ais.com/pub/2.11BSD/440-447.tar.bz2 With best regards, Walter Mueller From w.f.j.mueller at gsi.de Mon Jan 5 06:06:28 2009 From: w.f.j.mueller at gsi.de (Walter F. Mueller) Date: Sun, 04 Jan 2009 21:06:28 +0100 Subject: [pups] jove editor under 2.11BSD and cursor keys In-Reply-To: <4960F68E.1010507@gsi.de> References: <4960F68E.1010507@gsi.de> Message-ID: <496116C4.8050101@gsi.de> Hello, I'm using the jove editor under 2.11BSD, the jove release is from 1988. It works just fine, except for the cursor keys. Even though the ansi-codes function is properly bound, 'ESC x describe-bindings' shows: ESC [ ansi-codes I get whenever I hit one of the cursor keys the message [ESC O unbound] TERM is set to vt100, termcap is ok, and the xterm used is started with -ti vt100. vi for example works and accepts the cursor keys, a dump of the chars emitted by xterm show that the proper \[[A ect sequence indeed arrives. Any help or hint on how to get this to work is very much appreciated. With best regards, Walter Mueller From bqt at softjar.se Mon Jan 5 09:59:42 2009 From: bqt at softjar.se (Johnny Billquist) Date: Mon, 05 Jan 2009 00:59:42 +0100 Subject: [pups] jove editor under 2.11BSD and cursor keys In-Reply-To: <496116C4.8050101@gsi.de> References: <4960F68E.1010507@gsi.de> <496116C4.8050101@gsi.de> Message-ID: <49614D6E.2090408@softjar.se> Walter F. Mueller wrote: > Hello, > > I'm using the jove editor under 2.11BSD, the jove release is > from 1988. It works just fine, except for the cursor keys. > Even though the ansi-codes function is properly bound, > 'ESC x describe-bindings' shows: > > ESC [ ansi-codes > > I get whenever I hit one of the cursor keys the message > > [ESC O unbound] > > TERM is set to vt100, termcap is ok, and the xterm used is > started with -ti vt100. vi for example works and accepts the > cursor keys, a dump of the chars emitted by xterm show that > the proper \[[A ect sequence indeed arrives. > > Any help or hint on how to get this to work is very much > appreciated. Please note the difference between "[" and "O"... :-) To give you a little more help: someone or something is changing your terminal to have application cursor keys. (And to point out what should be obvious now: your cursor keys can actually send two different kind of codes, depending on a setup parameter.) Johnny From W.F.J.Mueller at gsi.de Tue Jan 6 06:06:51 2009 From: W.F.J.Mueller at gsi.de (Walter F.J. Mueller) Date: Mon, 05 Jan 2009 21:06:51 +0100 Subject: [pups] jove editor under 2.11BSD and cursor keys In-Reply-To: <49614D6E.2090408@softjar.se> References: <4960F68E.1010507@gsi.de> <496116C4.8050101@gsi.de> <49614D6E.2090408@softjar.se> Message-ID: <4962685B.30005@gsi.de> Johnny Billquist wrote: > Walter F. Mueller wrote: >> .... >> I get whenever I hit one of the cursor keys the message >> >> [ESC O unbound] >... > Please note the difference between "[" and "O"... :-) > > To give you a little more help: someone or something is changing your > terminal to have application cursor keys. > (And to point out what should be obvious now: your cursor keys can > actually send two different kind of codes, depending on a setup parameter.) > > Johnny Thanks Johnny, that was exactly the problem. jove sets the terminal (or the emulator) into 'Application Cursor Key' and 'Application Keypad' mode. Looking in xterm at the VT Options popup (with CONTROL-MB2) shows this nicely. Binding the 'ansi-codes' function of Jove 4.9 (that's what comes with 2.11BSD) to \[O resolves the cursor issue. What I still don't understand is why jove comes with defaults which don't work. It puts the cursor and keypad keys into application mode, which makes perfect sense especially for the keypad, and than looks for \[[ rather \[O. Probably to make retrocomputing more fun :). Thanks and with best regards, Walter From bqt at softjar.se Wed Jan 7 02:54:01 2009 From: bqt at softjar.se (Johnny Billquist) Date: Tue, 06 Jan 2009 17:54:01 +0100 Subject: [pups] jove editor under 2.11BSD and cursor keys In-Reply-To: References: Message-ID: <49638CA9.6010703@softjar.se> And most proper emacs (and clone) users don't use the arrow keys, but use ^P, ^N, ^F and ^B. So this particular problem don't show. :-) Jove is actually a pretty nice Emacs clone. I wonder if I should try to port it to RSX... Johnny robinb at ruffnready.co.uk wrote: > IIRC the version of Jove that is on 2.11 was put on by me back in the late 80s to replace an even earlier version and I used a VT220 at home as opposed to xterm or whatever on a sim. As a result I was quite happy with using the defaults for whatever was set up for the then available hardware as I used a real PDP with real DEC terminals :-) > > Cheers > > Robin > > PS: It may have been updated since then I can't really recall. > > W.F.J.Mueller at gsi.de wrote: >> Johnny Billquist wrote: >>> Walter F. Mueller wrote: >>>> .... >>>> I get whenever I hit one of the cursor keys the message >>>> >>>> [ESC O unbound] >>> ... >>> Please note the difference between "[" and "O"... :-) >>> >>> To give you a little more help: someone or something is changing your >>> terminal to have application cursor keys. >>> (And to point out what should be obvious now: your cursor keys can >>> actually send two different kind of codes, depending on a setup parameter.) >>> >>> Johnny >> Thanks Johnny, that was exactly the problem. jove sets the terminal >> (or the emulator) into 'Application Cursor Key' and 'Application Keypad' >> mode. Looking in xterm at the VT Options popup (with CONTROL-MB2) shows >> this nicely. Binding the 'ansi-codes' function of Jove 4.9 (that's what >> comes with 2.11BSD) to [O resolves the cursor issue. >> >> What I still don't understand is why jove comes with defaults which >> don't work. It puts the cursor and keypad keys into application mode, >> which makes perfect sense especially for the keypad, and than looks >> for [[ rather [O. Probably to make retrocomputing more fun :). >> >> >> Thanks and with best regards, Walter >> _______________________________________________ >> PUPS mailing list >> PUPS at minnie.tuhs.org >> https://minnie.tuhs.org/mailman/listinfo/pups >> > From robinb at ruffnready.co.uk Wed Jan 7 02:49:04 2009 From: robinb at ruffnready.co.uk (robinb at ruffnready.co.uk) Date: Tue, 06 Jan 2009 16:49:04 +0000 Subject: [pups] jove editor under 2.11BSD and cursor keys In-Reply-To: <4962685B.30005@gsi.de> Message-ID: IIRC the version of Jove that is on 2.11 was put on by me back in the late 80s to replace an even earlier version and I used a VT220 at home as opposed to xterm or whatever on a sim. As a result I was quite happy with using the defaults for whatever was set up for the then available hardware as I used a real PDP with real DEC terminals :-) Cheers Robin PS: It may have been updated since then I can't really recall. W.F.J.Mueller at gsi.de wrote: > Johnny Billquist wrote: > > Walter F. Mueller wrote: > >> .... > >> I get whenever I hit one of the cursor keys the message > >> > >> [ESC O unbound] > >... > > Please note the difference between "[" and "O"... :-) > > > > To give you a little more help: someone or something is changing your > > terminal to have application cursor keys. > > (And to point out what should be obvious now: your cursor keys can > > actually send two different kind of codes, depending on a setup parameter.) > > > > Johnny > > Thanks Johnny, that was exactly the problem. jove sets the terminal > (or the emulator) into 'Application Cursor Key' and 'Application Keypad' > mode. Looking in xterm at the VT Options popup (with CONTROL-MB2) shows > this nicely. Binding the 'ansi-codes' function of Jove 4.9 (that's what > comes with 2.11BSD) to [O resolves the cursor issue. > > What I still don't understand is why jove comes with defaults which > don't work. It puts the cursor and keypad keys into application mode, > which makes perfect sense especially for the keypad, and than looks > for [[ rather [O. Probably to make retrocomputing more fun :). > > > Thanks and with best regards, Walter > _______________________________________________ > PUPS mailing list > PUPS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/pups > From vasco at icpnet.pl Fri Jan 9 20:51:38 2009 From: vasco at icpnet.pl (Andrzej Popielewicz) Date: Fri, 09 Jan 2009 11:51:38 +0100 Subject: [TUHS] /usr/bin/bs on HPUX? In-Reply-To: <20081210180826.GE1746@mercury.ccil.org> References: <75D36093-D9D0-48EF-ACAC-DF739E0236B6@mac.com> <20081210180826.GE1746@mercury.ccil.org> Message-ID: <49672C3A.5020307@icpnet.pl> John Cowan pisze: > Lord Doomicus scripsit: > > >> I was poking around an HP UX system at work today, and noticed a >> command I've never noticed before ... /usr/bin/bs. >> >> I'm sure it's been there for a long time, even though I've been an >> HPUX admin for more than a decade, sometimes I'm just blind ... but >> anyway .... >> >> I tried to search on google ... it looks like only HPUX, AIX, and >> Maybe AU/X has it. Seems to be some kind of pseudo BASIC like >> interpreter. >> > > That's just what it is. Here are the things I now know about it. > > 0. The string "bs" gets an awful lot of false Google hits, no matter > how hard you try. > > 1. "bs" was written at AT&T, probably at the Labs, at some time between > the release of 32V and System III. It was part of both System III and > at least some System V releases. > > 2. It was probably meant as a replacement for "bas", which was a more > conventional GW-Basic-style interpreter written in PDP-11 assembly > language. (32V still had the PDP-11 source, which of course didn't work.) > > 3. At one time System III source code was available on the net, > including bs.c and bs.1, but apparently it no longer is. I downloaded > it then but don't have it any more. > > 4. I was able to compile it under several Unixes, but it wouldn't run: > I think there must have been some kind of dependency on memory layout, > but never found out exactly what. > > 5. I remember from the man page that it had regular expressions, and > two commands "compile" and "execute" that switched modes to storing > expressions and executing them on the spot, respectively. That eliminated > the need for line numbers. > > 6. It was apparently never part of Solaris. > > 7. It was never part of any BSD release, on which "bs" was the battleships > game. > > 8. I can't find the man page on line anywhere either. > > 9. The man page said it had some Snobol features. I think that meant > the ability to return failure -- I vaguely remember an "freturn" command. > > 10. 99 Bottles of Beer has a sample bs program at > http://www2.99-bottles-of-beer.net/language-bs-103.html . > > 11. If someone sends me a man page, I'll consider reimplementing it as > Open Source. > > You will find public domain basic interpreter in Coherent archive mwcbbs at lynx gopher://rachael.dyndns.org/1 It is for pdp11, vax, coherent , motorola etc. Andrzej From reed at reedmedia.net Wed Jan 14 10:59:40 2009 From: reed at reedmedia.net (Jeremy C. Reed) Date: Tue, 13 Jan 2009 18:59:40 -0600 (CST) Subject: [TUHS] historical users and groups Message-ID: 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! From harker at harker.com Wed Jan 14 17:28:02 2009 From: harker at harker.com (Robert Harker) Date: Tue, 13 Jan 2009 23:28:02 -0800 Subject: [TUHS] historical users and groups In-Reply-To: References: Message-ID: <496D9402.3060607@harker.com> 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 From jrvalverde at cnb.csic.es Wed Jan 14 23:00:34 2009 From: jrvalverde at cnb.csic.es (Jose R. Valverde) Date: Wed, 14 Jan 2009 14:00:34 +0100 Subject: [TUHS] historical users and groups In-Reply-To: References: Message-ID: <20090114140034.4e20ce6d@cnb.csic.es> 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" 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jrvalverde at cnb.csic.es Wed Jan 14 23:33:02 2009 From: jrvalverde at cnb.csic.es (Jose R. Valverde) Date: Wed, 14 Jan 2009 14:33:02 +0100 Subject: [TUHS] historical users and groups In-Reply-To: References: Message-ID: <20090114143302.0e0e607b@cnb.csic.es> 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: From tfb at tfeb.org Thu Jan 15 03:15:13 2009 From: tfb at tfeb.org (Tim Bradshaw) Date: Wed, 14 Jan 2009 17:15:13 +0000 Subject: [TUHS] historical users and groups In-Reply-To: References: Message-ID: <72C06F9F-BBDB-4473-9091-7131B7FFD073@tfeb.org> 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 From cowan at ccil.org Thu Jan 15 03:36:41 2009 From: cowan at ccil.org (John Cowan) Date: Wed, 14 Jan 2009 12:36:41 -0500 Subject: [TUHS] historical users and groups In-Reply-To: <72C06F9F-BBDB-4473-9091-7131B7FFD073@tfeb.org> References: <72C06F9F-BBDB-4473-9091-7131B7FFD073@tfeb.org> Message-ID: <20090114173641.GC22276@mercury.ccil.org> 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. From neozeed at gmail.com Fri Jan 16 03:15:46 2009 From: neozeed at gmail.com (Jason Stevens) Date: Thu, 15 Jan 2009 12:15:46 -0500 Subject: [TUHS] historical users and groups In-Reply-To: <20090114140034.4e20ce6d@cnb.csic.es> References: <20090114140034.4e20ce6d@cnb.csic.es> Message-ID: <46b366130901150915m66e31fccq38c2b0d0ed4f5d2f@mail.gmail.com> 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 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" 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: From angus at fairhaven.za.net Fri Jan 16 15:52:06 2009 From: angus at fairhaven.za.net (Angus Robinson) Date: Fri, 16 Jan 2009 07:52:06 +0200 Subject: [TUHS] historical users and groups In-Reply-To: <46b366130901150915m66e31fccq38c2b0d0ed4f5d2f@mail.gmail.com> References: <20090114140034.4e20ce6d@cnb.csic.es> <46b366130901150915m66e31fccq38c2b0d0ed4f5d2f@mail.gmail.com> Message-ID: <49702086.7080001@fairhaven.za.net> An HTML attachment was scrubbed... URL: