Date: Wed, 23 Oct 1996 01:57:56 -0400 (EDT) From: Tim Vanderhoek <hoek@freenet.hamilton.on.ca> To: "Marc G. Fournier" <scrappy@freefall.freebsd.org> Cc: mark@linus.demon.co.uk, freebsd-bugs@freefall.freebsd.org Subject: Re: bin/1351 Message-ID: <Pine.GSO.3.95.961023014012.17100A-100000@james.freenet.hamilton.on.ca> In-Reply-To: <199610230418.VAA02394@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 22 Oct 1996, Marc G. Fournier wrote: > Synopsis: security problem with mv(1) > > State-Changed-From-To: open-feedback > State-Changed-By: scrappy > State-Changed-When: Tue Oct 22 21:16:47 PDT 1996 > State-Changed-Why: > > Anyone out there familiar with mv, and, potentially, this bug? mv(1) itself is a kludge (IMO). There is a discussion archived in -bugs over bin/1375 where this comes up a couple of times. This bug, and probably many more, all exist in mv(1). mv(1) is just crawling with things that aren't perfect... If I understand the suggested fix correctly, it by itself won't fix the problem. My opinion is that as soon as mv(1) sees it can't retain the [ug]id, it should scream bloody murder and ask for direction (namely, skip this file or copy, but clear wrx bits for [gu]id). Maybe POSIX has something to say? My opinion is that mv(1) and cp(1) should be rewritten and merged into one program. I've played with this a little, and eventually might reach something I consider satisfactory... -- Outnumbered? Maybe. Outspoken? Never! tIM...HOEk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.3.95.961023014012.17100A-100000>