How does 'mv' rename directories?

[Blair P. Houghton]

In article <544 at isi.UUCP> mike at isi.UUCP (Mike Maloney) writes:
>Dear wizards,
>
>I was recently trying to figure out why the 'mv' command on a Microport 
>System V box would refused to rename directories.  The commands
>		cd
>		mkdir junk
>		mv junk junk2
>would elicit the response: mv: cannot link 'junk' and 'junk2'.
>(No, 'junk2' did not already exist.)  The same commands would work
>fine on another system RUNNING THE SAME OPERATING SYSTEM!

Was it really 'junk1' and 'junk2' and not two files with long pathnames
on different filesystems?

>I suspect that it is something subtle to do with permissions.  But anyway,
>this led me to wonder how the 'mv' command can rename directories at all.

Setuid root, and you can move the cpu.  (That's not the case, here, it's
just a funny thing to say.  I do that, sometimes...)  Oh, but it isn't
a "setuid program"...

>The Rochkind book shows an implementation of 'mv' using link() and unlink().
>If the target path is a directory it first checks to see if it already exists, 
>and if it does, fails.  If I understand him correctly, his version of 'mv' 
>must have the Set-UID bit set and be owned be root because only processes 
>with an effective UID of root can link directories.

Yep.  One other case:  if the source and destination are on different
filesystems, it should effectively do mkdir() and then copy the
directory recursively and then remove the source, again recursively.

I've seen this done, and I'm wondering how much more effective it is,
in software-installation routines by using tar(1) instead of a
recursive copy.  Any comments?

>But on Microport, Xenix, and Sun Unix 4.0, /bin/mv is -rwxr-xr-x and is
>owned by 'bin'.   How is 'mv' able to rename directories on a properly 
>working system?

Does mv not do setuid()?  The setuid bit tells the OS to make the
effective uid (that which is used to derive ownership) the owner of the
program, but doesn't alter the possibility that there's a uid change in
the program itself.  (Sounds of digging Bach out of a back pack -- a
Bachpach? :-S -- and rummaging around the indexed ref to setuid for
verification, then the smell of paraphrasing fills the air) Since the
owner of the files has placed his uid in the kernel's process table,
the setuid() system call is free to change the effective uid to that
one.  The process is now permitted to change your files.

Faux Plagiarism:

p. 197, Bach, The Design of the UNIX O. S.
"The real user ID identifies the user who is responsible for the
running process.  the effective user ID is used to assign ownership
of newly created files, to check file access permissions, and to check
permission to send signals to processes via the kill(2) system call."

				--Blair
				  "Now comes the pain wherein
				   kill(1) fails to setuid(2) to you
				   because you are su-personating
				   yourself from elsewhom..."