lclarke@questor.wimsey.bc.ca (Lawrence Clarke) (01/04/91)
Guess what ... Don't backup your hard disk to floppies if your signed on as user root ! After figuring out how to do the backup, i demonstrated the procedure to friend, and mistakenly entered ... dump 0uOf 0.86 /dev/rsd0a /dev/rsd0a which tried too backup the scsi drive to the scsi drive, which deleted the filesystem. If you create another user with OPERATOR privledge, then this command will not allow you too over write the filesystem. Also i should mention 2 corrections from my last posting ... the (r) in rsd0a stands for RAW not removable. there is no -j (for ejectable) command in restore. Just type restore if /dev/rfd0a /==============================================================\ | lclarke@questor.wimsey.bc.ca | c/o TRIUMF Operations | | larry@triumfcl.bitnet | University of B.C. Canada | | Compuserve: 70441,1776 | 4004 Wesbrook Mall | | Phone: +1 604 275-5902 | Vancouver, British Columbia | | FAX: +1 604 275-4184 | Canada V6T 2A3 | \==============================================================/
bb@reef.cis.ufl.edu (Brian Bartholomew) (01/04/91)
In article <7u98u2w163w@questor.wimsey.bc.ca> lclarke@questor.wimsey.bc.ca (Lawrence Clarke) writes: > ...and mistakenly entered [...] which tried too backup the scsi drive > to the scsi drive, which deleted the filesystem. As you found out, when you are root, the computer does what you tell it to, usually with no questions asked. The assumption is that you know what you are doing, moreso than the computer's programs can guess. In the future, I would suggest a more cautious, programming- style approach. For instance, once you get your backup routine debugged, write the commands into a shell script so that you don't have to remember and type them perfectly each time you want to use them. Just a thought. > Guess what ... Don't backup your hard disk to floppies if your signed > on as user root! > If you create another user with OPERATOR privledge, then this command > will not allow you too over write the filesystem. This is a nonesuch. You are probably thinking of VMS. Under UNIX, there is exactly one level of "privledge", which is called root. Either you have it, and are allowed to do anything, or you don't, and all the access control mechanisms apply. The whole idea of the single privledge is to get away from the morass of special-cases and security holes that result from an overcomplicated security scheme. Trust me, it's better this way. If your NeXT was a PC, Amiga, or Mac, you would always be operating as "root", because there is no access control in these operating systems. Your NeXT is *better* than these machines. Take advantage of the built-in firewalls by only performing operations as root when there is no other reasonable way to do them. -- "Any sufficiently advanced technology is indistinguishable from a rigged demo." ------------------------------------------------------------------------------- Brian Bartholomew UUCP: ...gatech!uflorida!mathlab.math.ufl.edu!bb University of Florida Internet: bb@math.ufl.edu
fischer@iesd.auc.dk (Lars P. Fischer) (01/04/91)
>>>>> On 4 Jan 91 06:15:16 GMT, bb@reef.cis.ufl.edu (Brian Bartholomew) said: Brian> In article <7u98u2w163w@questor.wimsey.bc.ca> Brian> lclarke@questor.wimsey.bc.ca (Lawrence Clarke) writes: Lawrence> ...and mistakenly entered [...] which tried too backup the scsi drive Lawrence> to the scsi drive, which deleted the filesystem. Brian> As you found out, when you are root, the computer does what you tell Brian> it to, usually with no questions asked. ... Brian> [recommends using shell script] The rules for being rot are simple: 1) don't be root 2) If you must be root, reconsider if it's really necessary 3) if you are root, read each command line a extra time before hitting return. Lawrence> If you create another user with OPERATOR privledge, then this command Lawrence> will not allow you too over write the filesystem. Brian> This is a nonesuch. You are probably thinking of VMS. Under UNIX, Brian> there is exactly one level of "privledge", which is called root. Brian> Either you have it, and are allowed to do anything, or you don't, and Brian> all the access control mechanisms apply. This is true for *userid's*, ie userid 0 (root) is the only one considered special by the kernel and the only one granted special permissions. There is, however, the *group* system. Each file is owned by a user and a group. A file has three sets of permissions: user, group, and world. You may write to a file if 1) you own the file and there is write permission for the owner 2) you are a member of the group of the file and there is write permission for the group, etc. (the rule is more complicated than that, but never mind...) Now, each user may be in several groups at ones. On machines with several users, groups would be used to allow (groups of) users to share files. It's a good idea to create a group for system maintenance. Members of this group would be allowed to, write to the raw floppy device, *read* from the raw SCSI disk (but *not* write), run the dump command, etc. Create such a group, grant it the permissions needed (using chmod and chgrp) and put you own username in the group. You are now allowed to dump the SCSI disk to the floppy but are *not* allowed to destroy the SCSI disk. Such a group is often called operator and would typically exists when the machine arrive from the vendor. I guess this is what Lawrence meant by "operator privilege". Brian> Take advantage of the built-in firewalls by only performing operations Brian> as root when there is no other reasonable way to do them. See rule 1) above (:-). If you set your system up in a reasonable way, you can make backup's without being root (rule 2). /Lars -- Lars Fischer, fischer@iesd.auc.dk | Q: How does a project get to be one CS Dept., Univ. of Aalborg, DENMARK. | year late? A: One day at a time.
clt@cs.purdue.EDU (Carrick Talmadge) (01/05/91)
In article <BB.91Jan4011516@reef.cis.ufl.edu> bb@reef.cis.ufl.edu (Brian Bartholomew) writes: >lclarke@questor.wimsey.bc.ca (Lawrence Clarke) writes: >> ...and mistakenly entered [...] which tried too backup the scsi drive >> to the scsi drive, which deleted the filesystem. > >> Guess what ... Don't backup your hard disk to floppies if your signed >> on as user root! > >> If you create another user with OPERATOR privledge, then this command >> will not allow you too over write the filesystem. > >This is a nonesuch. You are probably thinking of VMS. Under UNIX, >there is exactly one level of "privledge", which is called root. >Either you have it, and are allowed to do anything, or you don't, and >all the access control mechanisms apply. The whole idea of the single >privledge is to get away from the morass of special-cases and security >holes that result from an overcomplicated security scheme. I think that the above comments could use a bit of clarification. The hard disk should have the following permissions: crw-r----- 1 root operator 14, 0 Apr 5 1990 /dev/rsd0a This gives group operator read permission to the hard drive, but not write permission. Thus, all you need to do to protect yourself from accidently blowing away the file system on the hard disk is make the person who is dumping the hard disk a member of group operator (but *not* the super user!!!). To make yourself a member of group operator, first "su" to root, and then type: nidump . group | grep operator > #operator The file #operator should contain only the line operator:*:9:root Modify this line to read operator:*:9:root,me [substitute your desired priveledged account name(s) for "me"], then type niload . group < #operator You can alternatively use "NetInfoManager" to perform this task. I would recommend never backing up your files as root just to protect yourself from the above happenstance. I would also recommend following Brian Bartholomew's suggestion of automating the backup and restore process using shell scripts. Carrick Talmadge clt@physics.purdue.edu clt@hercules.cs.purdue.edu
eps@toaster.SFSU.EDU (Eric P. Scott) (01/05/91)
In article <12886@medusa.cs.purdue.edu> clt@cs.purdue.edu (Carrick Talmadge) writes: >The hard disk should have the following permissions: > > crw-r----- 1 root operator 14, 0 Apr 5 1990 /dev/rsd0a > >This gives group operator read permission to the hard drive, but not >write permission. (Anyone else interested in a CFD for comp.sys.next.humor?) As a previous poster mentioned, this isn't VAX/VMS, and there ain't no such thing as READALL privilege. What good does read access to the raw device give you? Nothing!!! What were you planning to do? Image copy the bits? Good luck ever restoring anything from *that*. The only way you're going to get anything useful on backup media is if you read the disk ->through the filesystem<-. You know what it takes to do that? [dramatic pause] You have to be root! Nothing less will do, unless you want to reimplement most of the filesystem code in user mode (decidely nontrivial) (or hack the kernel, but that's asking too much). Trying to circumvent the file system on a disk that's currently mounted read/write is probably not such a hot idea. (Am I being too subtle?) If you can't use the standard tools without trashing things, write a front-end shell script that won't do anything too stupid. -=EPS=-
fischer@iesd.auc.dk (Lars P. Fischer) (01/06/91)
>>>>> On 5 Jan 91 06:17:38 GMT, eps@toaster.SFSU.EDU (Eric P. Scott) said:
Eric> (Anyone else interested in a CFD for comp.sys.next.humor?)
Nah, NeXT is good laugh as is is ... :-)
Eric> As a previous poster mentioned, this isn't VAX/VMS, and there
Eric> ain't no such thing as READALL privilege. What good does read
Eric> access to the raw device give you? Nothing!!! What were you
Eric> planning to do? Image copy the bits? Good luck ever restoring
Eric> anything from *that*. The only way you're going to get anything
Eric> useful on backup media is if you read the disk ->through the
Eric> filesystem<-. You know what it takes to do that?
Eric> [dramatic pause]
Eric> You have to be root!
You write fine dramatic prose, but im sorry to report that it won't
help you; you're quite wrong. "dump" actually reads the raw file
system. It does *not* go through the file system. Why do you think you
specify the raw SCSI device as an argument to dump?
I've been a UNIX sysadm for quite a few years now, and I can't
remember when I last did an ordinary dump as root. It has worked on
just about every UNIX box I've come a cross -- even on a PC, but don't
tell anyone I said that.
Eric> If you can't use the standard tools without trashing things,
Eric> write a front-end shell script that won't do anything too stupid.
It has already been written. It's called "dump". Nice, isn't it?
/Lars
--
Lars Fischer, fischer@iesd.auc.dk | Q: How does a project get to be one
CS Dept., Univ. of Aalborg, DENMARK. | year late? A: One day at a time.clt@cs.purdue.EDU (Carrick Talmadge) (01/06/91)
On 5 Jan 91 06:17:38 GMT, eps@toaster.SFSU.EDU (Eric P. Scott) puts his foot in his mouth:
Eric> As a previous poster mentioned, this isn't VAX/VMS, and there
Eric> ain't no such thing as READALL privilege. What good does read
Eric> access to the raw device give you? Nothing!!! What were you
Eric> planning to do? Image copy the bits? Good luck ever restoring
Eric> anything from *that*. The only way you're going to get anything
Eric> useful on backup media is if you read the disk ->through the
Eric> filesystem<-. You know what it takes to do that?
Eric>
Eric> [dramatic pause]
Eric>
Eric> You have to be root!
In article <FISCHER.91Jan5183537@thiele.iesd.auc.dk> fischer@iesd.auc.dk (Lars P. Fischer) responds:
Lars> You write fine dramatic prose, but im sorry to report that it won't
Lars> help you; you're quite wrong. "dump" actually reads the raw file
Lars> system. It does *not* go through the file system. Why do you think you
Lars> specify the raw SCSI device as an argument to dump?
Lars>
Lars> I've been a UNIX sysadm for quite a few years now, and I can't
Lars> remember when I last did an ordinary dump as root. It has worked on
Lars> just about every UNIX box I've come a cross -- even on a PC, but don't
Lars> tell anyone I said that.
Lars>
Lars is correct -- dump does not go through the file system to perform
backups. This is why it is a fairly efficient means of performing
system dumps. It is actually not very difficult to read files directly
off of a raw disk device; I have written which does exactly this sort of thing.
We *never* perform tape dumps as root on our system [physics.purdue.edu].
We have a user "operator" which has as its login group "operator".
Our tape monkey logs into this group to perform the daily incremental
backups on our system. And yes, Eric, we are able to successfully
restore files dumped via our operator account.
Carrick Talmadge
clt@physics.purdue.edu
clt@hercules.cs.purdue.edueps@toaster.SFSU.EDU (Eric P. Scott) (01/06/91)
In article <FISCHER.91Jan5183537@thiele.iesd.auc.dk> fischer@iesd.auc.dk (Lars P. Fischer) writes: >It has already been written. It's called "dump". Nice, isn't it? Not for us. (1) At least in the 1.0 release, dump has not worked reliably. This may have changed--we don't have 2.0 yet and we don't know when we're getting it--or our NeXTstations. Our procurement has been held up... something about verifying that NeXT hires a certain number of women and minorities. (Government regulations, y'know.) (2) While it may be ok for a standalone system, in our bizarre networked environment, it's not always reasonable--dump and rdump are specially hacked by NeXT (the documentation even says that it won't work with non-NeXT machines). Generally, the backup device is not going to be attached to the machine being backed up, and may not even be on a NeXT--I have a lot more faith in tar from an NFS-mounted partition. Will NeXT guarantee full interchangeability with Suns, for example? -=EPS=-
eps@toaster.SFSU.EDU (Eric P. Scott) (01/06/91)
To those of you who sent e-mail, thanks, I'll try to summarize and clarify: + dump does indeed read raw devices. It's highly questionable to use this on your root filesystem. + On most UNIX systems, the root filesystem is fairly small (8-40MB), and contains only the kernel, essential utilities, and configuration/authorization information. For the most part, there is no need to back it up--it doesn't change (except for a handful of files, mostly in /etc), and if destroyed can be recreated from original distribution media. /usr and user files are not on the root, so they don't pose a problem. Swap space is often a separate partition as well. None of this is true for small NeXT systems. + Filesystems backed up with dump should be dismounted (or mounted read-only) and clean according to fsck. To back up a single-partition system, one would presumably have to boot from a diskette. (Lots of pitfalls here.) + dump will only work for ufs filesystems. + NeXT's rdump may not be interoperable with non-NeXT versions. My (limited) experience with NeXT 1.0 dump has not been favorable. Given that we have optical drives, Exabytes, and networked storage at our disposal, I haven't been in the awkward position many new NeXTstation owners will find themselves in. I'm sure it's a solvable problem, I just don't believe there are currently any adequate solutions. (Should I say, "shareware opportunity?") -=EPS=-