Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!mips!apple!motcsd!mcdcup!mcdchg!tellab5!mtcchi!levy
From: levy@mtcchi.uucp (2656-Daniel R. Levy(0000000)0000)
Newsgroups: comp.unix.wizards
Subject: Re: Hard links to directories: why not?
Message-ID: <1990Aug28.210155.4492@mtcchi.uucp>
Date: 28 Aug 90 21:01:55 GMT
References: <18461@rpp386.cactus.org> <1990Jul22.035130.12559@zoo.toronto.edu> 	<18466@rpp386.cactus.org> <3724@auspex.auspex.com> 	<18468@ <1990Jul23.083256.17790@athena.mit.edu>
Organization: Memorex Telex Corporation NSBG/STP
Lines: 25

jik@pit-manager.mit.edu (Jonathan I. Kamens) writes:

>  The "correct" solution, perhaps, is to make mv check for special
>files after the rename() fails, and to use the mknod code to recreate
>special files.  The problem with this is that it would require mv to
>be setuid. Perhaps a better solution would be for mv to notice
>special files and print out an error like "cannot rename special files
>across partitions"; that is, after all, what it used to print when you
>tried to mv regular files across partitions (without the word
>"special").

How about requiring the user to have an effective uid of 0?  ("must be root to
move /dev/barf to /usr/tmp/barf") Having "mv" setuid gives me the willies.  Too
much room for a poor implementation to be fooled into doing something that the
normal UNIX protections would otherwise disallow.

>Jonathan Kamens			              USnail:
>MIT Project Athena				11 Ashford Terrace
>jik@Athena.MIT.EDU				Allston, MA  02134
>Office: 617-253-8495			      Home: 617-782-0710
-- 
 * Daniel R. Levy * uunet!tellab5!mtcchi!levy * This is not on behalf of MTC *
So far as I can remember, there is not one    | ... therefore be as shrewd as
word in the Gospels in praise of intelligence.| serpents [see Gen. 3] and harm-
-- Bertrand Russell [Berkeley UNIX fortune]   | less as doves -- JC [Mt. 10:16]