From owner-freebsd-fs@FreeBSD.ORG Tue Apr 15 07:12:52 2003 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2737337B401 for ; Tue, 15 Apr 2003 07:12:52 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id E643643F3F for ; Tue, 15 Apr 2003 07:12:50 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id AAA30745; Wed, 16 Apr 2003 00:12:37 +1000 Date: Wed, 16 Apr 2003 00:12:37 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Mark Day In-Reply-To: <627913C9-6ED3-11D7-A790-00039354009A@apple.com> Message-ID: <20030415233658.E1376@gamplex.bde.org> References: <627913C9-6ED3-11D7-A790-00039354009A@apple.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Yoshihiko Sarumaru cc: fs@freebsd.org Subject: Re: time stamp on msdosfs could not be set by general user X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2003 14:12:52 -0000 On Mon, 14 Apr 2003, Mark Day wrote: > On Saturday, April 12, 2003, at 10:06 AM, Yoshihiko Sarumaru wrote: > > > mistral% cp -p somefile /dos/ > > cp: utimes: /dos/somefile: Operation not permitted > > cp: chmod: /dos/somefile: Operation not permitted > > > > I can understand errors about chmod, but I can not understand errors > > about utimes and modified time could not be set at all. > > This is a consequence of the user and group IDs not being settable > per-file on DOS volumes. In effect, the user and group IDs are being > changed behind your back. Not really behind one's back. They are set to constants determined at mount time, and whoever had mount permission usually has permission to decide them. > > Below patch ignores unmatching of user and file owner > > Which means that the user who did the "cp" is not the same as the user > associated with the volume (the one who owns everything on that volume > -- which is settable via a mount option). > > But since you were able to create the file in the first place, the user > doing the cp must have had write access (as part of the group, or > world). It is also settable via chown on the mount point (before mounting). I use root:msdosfs and am in group msdosfs so that I can access them like I want except for this problem. > Workarounds would be to do the cp as root, or mount the volume as owned > by the same user as the one doing the cp. Neither is what I like. I normally do "cp -p somefile /dospartition/somewhere", then say "@&*@^" and switch to another terminal running a root shell and repeat the copy, except when copying a lot of files I use root too much. > > Any objection ? > > Hard to say. It violates the documented behavior of utimes -- that > only the owner should be able to modify the times. But if the volume > properly stored user and group IDs, you would have been the owner of > the file, and the utimes would have worked in this case. > > Your change would allow utimes to work even for a file you didn't just > create, as long as you had write access. That's potentially a security > problem, but msdosfs doesn't really have security to begin with. I don't like ignoring the ownerships completely. Perhaps relaxing the ownership check to a group membership check would be acceptable. msdosfs honors the ownerships for everything now, so it is no more insecure than the configured ownerships permit. Not that utimes with a null arg works now, since that only requires write permission. So we can change the timestamps to "now" by using utimes(). This is OK (not just for msdosfs) since it is nothing more than we could do using write()+truncate() and read(). > For comparison, Darwin and Mac OS X generally avoid the problem by the > way they manage the user ID. By default, everything on a msdosfs > volume is owned by a special user ID that gets mapped dynamically to > whoever is logged in at the console. For the one-user-at-a-time case, > this works well. But a different user would get the same behavior you > see. FreeBSD only has non-dynamic mapping via /etc/fbtab. This isn't quite enough even for a one-user system since everything normally get mounted before anyone can log in. Bruce