How does 'mv' rename directories?

[Blair P. Houghton]

In article <1160 at virtech.UUCP> cpcahil at virtech.UUCP (Conor P. Cahill) writes:
>In article <4158 at buengc.BU.EDU>, bph at buengc.BU.EDU (Blair P. Houghton) writes:
>> 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.
>
>The only ids a program can setuid() to are as follows:
>
>	1. the effective user id of the process 
>	2. the real user id of the process
>	3. (for system V) the "saved" user id of the process.

Okay.  Nothing odd there.

>	The exception is if either the real user id or effective user id
>	of the process is root, these limitations are rescinded
>
>  (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.

The real uid is the caller's uid.

>I'm not sure what you are talking about, but it sounds like you are talking
>about the method the kernel uses to interpret/execute the setuid-bits on
>the file.

No, That's what I was talking about up there where it says "setuid bit tells
the OS..."  Now, I'm talking about seteuid(getuid()), which makes the
process-owner the owner of any files created by the process, and allows
the process to access any files owned by the process owner.

>This automatically sets the effective user id and allows the program
>to change it's "real" user id to match the effective user id (or to change
>the effective user id back to the real user id) by using the setuid() syscall.

Like I said I said.  (Hey.  Now _I_ am starting to get lost... :-)

>If you aint root, the only way to get root uid privileges is to run a
>setuid-root program.

True, but not in the paragdigm for mv(1).

You only want mv(1) to be able to seteuid(2) to you, so you can move
your own files.  If mv(1) was setuid-root, you could move files all
over the place, without a care.  Hence, mv(1) is most definitely
not setuid-root.

I've been told that mv(1) may call mv_dir(?) (which doesn't exist
on this machine... Encore's Umax is a vanilla BSD...) which is
setuid-root (it is claimed).  If this is how it's done, then the
reason for the setuid-root could be to allow the moving of a
directory across partition boundaries when the directory may
contain files with an owner different from the directory-owner.

Moving from one partition to the next requires a copy-then-unlink,
whereas moving within a partition only requires a link-then-unlink.

Linking to a file is a thing done on the directory containing that
file, and so requires only the permission of the directory.  Copying
the file, however, requires permission to read from that file.

The destination-writing can be accomplished by chown'ing once the file
is written, but the source-reading absolutely requires the permission.

But, basically, there's no need to become uid 0 when you're just moving
files around in a partition.

				--Blair
				  "Maybe.  It's too much
				   blither and not enough
				   snarl.  Is it clear?"