Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 11 Jul 1996 18:03:28 +1000
From:      Bruce Evans <bde@zeta.org.au>
To:        wollman@lcs.mit.edu, zach@blizzard.gaffaneys.com
Cc:        bde@zeta.org.au, freebsd-bugs@freefall.freebsd.org, mrm@MARMOT.Mole.ORG
Subject:   Re: bin/1375: Extraneous warning from mv(1)
Message-ID:  <199607110803.SAA19123@godzilla.zeta.org.au>

next in thread | raw e-mail | index | archive | help
>I read the man page for what cp(1) is supposed to do regarding
>permissions (I didn't verify that works as advertised), and I don't
>think its behavior as documented covers all the bases very well when
>applied to mv(1).  mv(1) really really wants to preserve the precise
>mode and ownership flags, but cp(1) merely gives it a good effort, if
>you tell it to.  But since it is simply copying, cp(1) doesn't
>complain if preserving the flags is impossible.  These issues are also

Right.

>valid for archival programs like tar, cpio, pax, etc.. since they are
>always "moving" files across "filesystems".

Note that none of these supports file flags, even for pass-through mode
in cpio and pax.

>First, regarding the filesystem flags, I think we all can agree that
>some of the flags should be preserved when moving across filesystems.
>The question is which ones? Obviously uchg and schg files need to be
>left completely alone, but what about the dump flag?  I'm not

uchg and schg should prevent moving (they prevent unlinking) and nodump
should be preserved.

>completely sure what that means (the man page helpfully says that if
>the nodump flag is set, the file should never be dumped.  Dumped

It means that you don't want the file backed up much.  This is explained
OK in dump(8).  install(1) preserves all flags except the nodump flag.

uappnd and sappnd should be handled like uchg and schg.

`arch' is the only flag whose handling isn't obvious.  Perhaps it should
be cleared by moving to a different file system so that the file gets
archived in its new place.  It isn't honoured by any archivers except
msdosfs ones.

>Next, about the file-mode mask.  When should the other read, write,
>execute/search; group read, write, execute/search; setgid; and setuid
>bits be ok to preserve, and when should some or all of them be
>dropped?  This will probably have to depend on the umask setting when
>deciding if to keep the write, read or execute bits when either the
>owner, gid, or both have to change.  Consider these situations:

Bits should never be dropped, except possibly the set*id bits.  mv
should not set the set*id bits before copying the whole file.  Perhaps
it should create the target file with a mode of 0600 and set the bits
last.  The fastmove() case of mv currently creates the target with the
mode of the source.  cp is more careful.

>1) There is a file with the mode '-rwxrwsr-x', and you need to move it
>to a public bin directory on a different filesystem.  You do not own
>the file, but one of your gids is the same as the file's gid.  You
>have write permissions to the directory you are moving to (perhaps the
>bits are 'drwxrwxr-x').  After mv(1) finishes, what permissions should
>the file have?  I say the bits should be '-rwxrwsr-x' with you as the
>new owner, but the file still has the original gid.

This seems reasonable, but I would prefer this case to fail.

>2) The original file has the mode bits '-rwsrwsr-x'.  Obviously, if
>you are not the owner, the setuid and probably the setgid bit should
>be dropped.  Should mv(1) print out a message saying it dropped them?
>I think so.  Should the move succeed at all?  The answer is debatable,
>but I'm beginning to think it should not, even if you could simulate
>the move with appropriate calls to rm(1), cp(1), chmod(1), and
>chgrp(1).

Now I'm even more convinced that all cases where a mode would change
should fail :-).  This is for mv.  Archivers should behave more like cp.
Does cp actually do the wrong thing in any cases?  What should cp -p
do with the mode if it can't preserve the ids?

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607110803.SAA19123>