Date: Wed, 26 Jun 1996 02:36:22 GMT From: Mark Valentine <mark@linus.demon.co.uk> To: FreeBSD-gnats-submit@freebsd.org Subject: bin/1351: security problem with mv(1) Message-ID: <199606260236.CAA08997@linus.demon.co.uk> Resent-Message-ID: <199606260150.SAA22457@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 1351 >Category: bin >Synopsis: security problem with mv(1) >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Jun 25 18:50:02 PDT 1996 >Last-Modified: >Originator: Mark Valentine >Organization: >Release: FreeBSD 2.2-CURRENT i386 >Environment: n/a >Description: There appear to be several bugs in mv(1) which might result in a file being readable and/or writeable by unauthorised users during and after a cross-device 'move' - see function fastcopy(). One example is a file with mode 660, group 'bin', created in /tmp. If I move this to my home directory (I'm not in group 'bin'), mv warns me about `set owner/group: Operation not permitted', yet leaves the file writeable by anyone in the group to which my home directory belongs. Even in cases where the final fchown() will succeed, there's a window during the move (which may be significant for a large move across file systems) in which the same problem exists (at least for read permissions). I'm sure it's possible to imagine more serious real world examples - I only contrived this example because I spotted it while trying to figure out whether it's valid to shut up mv about the failed fchown() - I note that SunOS 5.5 mv doesn't give the warning, but has part of the bug (in an example similar to the one above, it left the target file readable but not writeable to the wrong group). (Another bug involves failing to remove the target when hit by a signal during the copy, but I think I remember some discussion on that one already.) >How-To-Repeat: $ touch /tmp/foo $ chmod 660 /tmp/foo $ mv /tmp/foo $HOME (For the last part, I used a small file and added a sleep to fastcopy()...) >Fix: The second problem might be fixed by moving the fchown/fchmod to between the open and read/write loop. >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606260236.CAA08997>