Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: Why does "root" own everything?
Message-ID: <10652@mimsy.UUCP>
Date: 15 Mar 88 14:06:58 GMT
References: <5209@uwmcsd1.UUCP> <9269@sunybcs.UUCP> <7454@brl-smoke.ARPA> <3755@bloom-beacon.MIT.EDU>
Distribution: na
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 29

In article <3755@bloom-beacon.MIT.EDU> wesommer@athena.mit.edu
(William E. Sommerfeld) writes:
>If you're using the 4.x-oid `dump' and `restore', it's simple.  Dump
>reads the raw disk, so all you have to do is to create a `backup'
>pseudo-user and give it group read (but not write) access the raw
>devices you want to have backed up.

An easier way:

	% ls -lgd /etc /etc/{,r}dump /etc/dumpdates /dev/rra1d
	drwxr-xr-x 12 bin      bin          5120 Mar 15 05:45 /etc
	-rwxr-s---  1 bin      operator    36864 Nov 18 15:34 /etc/dump
	-rwsr-s---  1 root     operator    51200 Nov 18 15:34 /etc/rdump
	-rw-rw-r--  1 bin      operator     5544 Mar 15 08:56 /etc/dumpdates
	crw-r-----  1 root     operator   9,  11 Mar 13 19:56 /dev/rra1d
	%

This depends on the fact that new versions of /etc/dump open
/etc/dumpdates in mode `r+' and use ftruncate() to shorten the file
when necessary (hence dump and rdump no longer need write permission on
/etc).  (rdump must still run setuid-root so as to get a restricted
port.)

Incidentally, in 4.3-tahoe (and around here, ever since we installed
4.2BSD) root does not own everything.  Now `bin' owns everything that
need not be special.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris