Date: Mon, 14 Apr 2003 16:46:59 -0700 From: Mark Day <mday@apple.com> To: mistral@imasy.or.jp (Yoshihiko Sarumaru) Cc: fs@freebsd.org Subject: Re: time stamp on msdosfs could not be set by general user Message-ID: <627913C9-6ED3-11D7-A790-00039354009A@apple.com> In-Reply-To: <030413020639.M0101472@mistral.imasy.or.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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). 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. > 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. 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. -Mark
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?627913C9-6ED3-11D7-A790-00039354009A>