time stamp on msdosfs could not be set by general user

[Bruce Evans]

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