Inspired by a recent post http://marc.info/?l=openbsd-misc&m=118999679514195 I was wondering if the participants in firstname.lastname@example.org would help me brainstorm. I want to give the operator group greater permissions than it currently has, so that any member of the group can perform most of the basic actions of a system administrator or desktop/laptop owner, without resorting to sudo. Of course, this is not without some risk, but the acid test I will use is: (1) Is permission to perform the action required by most desktop/laptop owners and low-level system administrators during routine or everyday work? (2) If "yes", then does permitting the operator group to perform this action expose the system to no more risk than permitting the individual to perform the action with sudo? The idea is that if almost everybody is giving themselves these permissions with sudo, then we might as well automatically grant these permissions to members of the operator group. The first thing on my wish-list is greater device access. The operator should have read/write access to many of the devices in /dev, especially USB drives, tape drives, and CD drives. This could be accomplished by giving the devices operator ownership. But which devices shouldn't the operator have read/write access to? And then there is CD/DVD burning. What permissions does an operator need to burn a CD or DVD (with cdrecord or growisofs) without logging in as root?
USB, CD drives -> sounds like a job that could be done with amd(8). tape drives -> operator already has rw.
I agree, except that there's the warning that you don't put anyone in sudo that you wouldn't trust with root access. Lets take a typical family setup. Mom is the SA who knows the root password. Dad can be operator and do stuff with sudo. However, the kids may just want to listen to CDs, watch DVDs, access their homework on a USB stick, rip a CD to MP3 and transfer it to their player or move MP3s from their player and burn them to a CD. Is it appropriate for the kids to use sudo or is there a security risk since you do not want the kids to get root. They may also need to have the modem access the internet. I don't know However, suppose you want to mount a USB/CD, check something, unmount it, and mount another? I don't see a way to tell amd to unmount before it timesout. ---- Your suggest is similar to the way devices are handled in Debian. On my Debian box, I'm in the following groups for the following reasons: dtutty: standard default login group adm: so I can read logs dialout: so I can use minicom to access the modem directly cdrom: so I can mount the cdrom, burn CDs, etc floppy: ditto for floppies audio: so I can adjust the mixer settings and hear music and movies dip: so I can pon the internet video: so I can watch movies plugdev: so I can mount and access USB sticks, Palm, etc staff: similar to OBSD's operator group. ssh: So I can limit who can run ssh. The definitive info on groups in Debian comes from the documentation with the base-passwd package in the users-and-groups.html file which I can email to you if you like: 19 KB in html, 5.3 KB in text. The document itself is under the GPLv2 but you will only be reading it not modifying it to include in OBSD :)) ------ If it weren't for the warnings about sudo and people you don't trust with root, I think that using sudo with groups is the best approach. Then you don't have to change bits of the system all over the place. It _may_ (I don't know) be easier or better to close any security ...
Actually, I was envisioning that the kids would have operator permissions. I was thinking that an "operator" is anyone who has physical access to the computer and is expected to use the hardware. I don't know the history of the operator group, but it almost seems as if it dates back to the days when BSD ran on mainframes whose only form of removable media was a tape drive. Of course, computers are being used much differently nowadays, so it makes sense to update the operator group. Or, alternatively, maybe the operator group has become obsolete with the advent of sudo? In that case, perhaps the operator group should be abolished, because I get the feeling that the operator group, in its current form, isn't serving any real purpose.
It comes from the job description of "Computer Operator". You know what a Systems Administrator is, operator is a much lower profile junior job. In large companies, operators often work the graveyard shift and operate It is used by backup apps, such as amanda (in ports). It can also be used by your local backup scripts to dump slices. Maybe there is need for an additional group for other functions that are now more common? So you could be added to operator and desktop (or whatever name is better)
For a while I supported Sun's Netconnect service, which is a fancy Nagios for Solaris. It watches the logs for patterns and reports on system availability. But when German speaking customers took it on they reported terrible uptime stats; it was grepping for the the word "halt"!
|Kay Sievers||Re: char/tpm: tpm_infineon no longer loaded for HP 2510p laptop|
|Eric W. Biederman||[PATCH 8/8] sysfs: user namespaces: fix bug with clone(CLONE_NEWUSER) with fairsched|
|S K||Re: cpufreq doesn't seem to work in Intel Q9300|
|Bart Van Assche||Re: Is gcc thread-unsafe?|
|Greg Kroah-Hartman||[PATCH 20/36] Driver core: Call device_pm_add() after bus_add_device() in device_a...|
|Junio C Hamano||Re: git-svnimport|
|Junio C Hamano||Re: [PATCH] git-mv: Keep moved index entries inact|
|Johannes Schindelin||Re: [PATCH] Fix approxidate("never") to always return 0|
|A Large Angry SCM||Re: [RFC] origin link for cherry-pick and revert|
|Gabriel||[PATCH] When a remote is added but not fetched, tell the user.|
|Daniel Lezcano||getsockopt(TCP_DEFER_ACCEPT) value change|
|David Miller||Re: 126.96.36.199: bnx2/tg3: BUG: "scheduling while atomic" trying to ifenslave a seco...|
|Ingo Molnar||Re: [regression] nf_iterate(), BUG: unable to handle kernel NULL pointer dereference|
|Eric W. Biederman||[PATCH 14/20] net: Simplify pppol2tp pernet operations.|
|Jeff Kirsher||[net-2.6 PATCH 2/5] e1000e: increase swflag acquisition timeout for ICHx/PCH|
|Linux Kernel Mailing List||ath9k_htc: Allocate URBs properly|
|Linux Kernel Mailing List||sm501: add power control callback|
|Linux Kernel Mailing List||MIPS: Cavium: Remove unused watchdog code.|
|Linux Kernel Mailing List||V4L/DVB (8976): af9015: Add USB ID for AVerMedia A309|
|Linux Kernel Mailing List||ARM: 5670/1: bcmring: add default configuration for bcmring arch|
|daniele.pilenga||snmpd hangs on 4.1 looking up hrSWRunTable|
|Jason Dixon||Re: any web management gui for pf ?|
|Christophe Rioux||Implementation example of snmp|
|Nick Holland||Re: booting openbsd on eee without cd-rom|
|Bryan Irvine||Re: OpenBSD 4.7 Released, May 19 2010|