From owner-freebsd-bugs Fri Apr 25 09:01:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA23983 for bugs-outgoing; Fri, 25 Apr 1997 09:01:21 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA23971 for ; Fri, 25 Apr 1997 09:01:17 -0700 (PDT) Received: from net2.netview.net (netview.net [199.3.74.250]) by who.cdrom.com (8.8.5/8.6.11) with ESMTP id IAA24735 for ; Fri, 25 Apr 1997 08:44:05 -0700 (PDT) Received: from watney (ip71-188.ts.netview.net [199.3.71.188]) by net2.netview.net (8.8.5/8.8.5) with SMTP id KAA02425; Fri, 25 Apr 1997 10:39:41 -0500 (EST) Date: Fri, 25 Apr 1997 10:39:41 -0500 (EST) Message-Id: <3.0.32.19970425103837.00a79210@199.3.74.250> X-Sender: jc@199.3.74.250 X-Mailer: Windows Eudora Pro Version 3.0 (32) To: bugs@freebsd.org, Bruce Evans From: John Clark Subject: Re: owner sticky and mv Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Bruce, >>I think I have found a bug while moving (mv) files from one filesystem to >>another. Files that are owner sticky (in this case root) do not transfer >>their permissions properly. > >This may be a feature. The kernel rejects attempts by non-root to set >the sticky bit for non-directories. mv(1) has no idea that the problem >is caused by the sticky bit, so it doesn't try another chmod() to set >the other bits. The sticky bit has no direct effect for non-directories, >so perhaps is was being used by root to inhibit moving files :-). Try this (as root): NOTE: To demonstrate this bug, you have to be moving a subdirectory across file systems. This assumes that '/root' and '/var' are on different filesystems. mkdir /var/d1 mkdir /var/d1/test touch /var/d1/test/f1_rw touch /var/d1/test/f2_rw touch /var/d1/test/f1_nn touch /var/d1/test/f2_nn chown root.wheel /var/d1/test/f1_rw chown root.wheel /var/d1/test/f2_rw chown nobody.nogroup /var/d1/test/f1_nn chown nobody.nogroup /var/d1/test/f2_nn chmod 4555 /var/d1/test/f1_rw chmod 555 /var/d1/test/f2_rw chmod 4555 /var/d1/test/f1_nn chmod 555 /var/d1/test/f2_nn ls -al /var/d1/test At this point you should see the obvious: drwx------ 2 root wheel 512 Apr 25 10:27 ./ drwx------ 3 root wheel 512 Apr 25 10:27 ../ -r-sr-xr-x 1 nobody nogroup 0 Apr 25 10:27 f1_nn* -r-sr-xr-x 1 root wheel 0 Apr 25 10:27 f1_rw* -r-xr-xr-x 1 nobody nogroup 0 Apr 25 10:27 f2_nn* -r-xr-xr-x 1 root wheel 0 Apr 25 10:27 f2_rw* now: mv /var/d1/test /var ls -al /var/test moving the subdir on the same filesystem, everything is ok: drwx------ 2 root wheel 512 Apr 25 10:30 ./ drwxr-xr-x 20 root wheel 512 Apr 25 10:30 ../ -r-sr-xr-x 1 nobody nogroup 0 Apr 25 10:27 f1_nn* -r-sr-xr-x 1 root wheel 0 Apr 25 10:27 f1_rw* -r-xr-xr-x 1 nobody nogroup 0 Apr 25 10:27 f2_nn* -r-xr-xr-x 1 root wheel 0 Apr 25 10:27 f2_rw* now: mv /var/test /root ls -al /root/test we see that any files owned by the mover get stripped: drwx------ 2 root wheel 512 Apr 25 10:32 ./ drwxr-x--- 9 root wheel 512 Apr 25 10:32 ../ -r-sr-xr-x 1 nobody nogroup 0 Apr 25 10:27 f1_nn* -r-s------ 1 root wheel 0 Apr 25 10:27 f1_rw* -r-xr-xr-x 1 nobody nogroup 0 Apr 25 10:27 f2_nn* -r-xr-xr-x 1 root wheel 0 Apr 25 10:27 f2_rw* I am using umask 077, although it should not affect an 'mv' process. umask of 007: drwx------ 2 root wheel 512 Apr 25 10:33 ./ drwxr-x--- 9 root wheel 512 Apr 25 10:33 ../ -r-sr-xr-x 1 nobody nogroup 0 Apr 25 10:27 f1_nn* -r-sr-x--- 1 root wheel 0 Apr 25 10:27 f1_rw* -r-xr-xr-x 1 nobody nogroup 0 Apr 25 10:27 f2_nn* -r-xr-xr-x 1 root wheel 0 Apr 25 10:27 f2_rw* This is a bug, 'mv' looks at umask of files owned by the mover uid when moving across filesystems. Thanks, John Clark [email@john.net]