openssh bugs - Mar 2004 - [Bug 823] Rename fails on fat32 partitions

http://bugzilla.mindrot.org/show_bug.cgi?id=823

           Summary: Rename fails on fat32 partitions
           Product: Portable OpenSSH
           Version: 3.8p1
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: major
          Priority: P2
         Component: sftp-server
        AssignedTo: openssh-bugs at mindrot.org
        ReportedBy: iwish at musician.org


I have found that in the static void process_rename(void) function of
sftp-server.c when a file being renamed in Linux (and I assume all types on
UN*Xs) is mounted on a fat32 partition the rename fails.This may effect other
non-posix filesystem files as well.

I tracked the problem down to the link(oldpath, newpath) == -1) failing, since
the S_ISREG(sb.st_mode) condition is met with a fat32 mounted filesystem file. I
found that if the link() fails falling back on rename() works to remedy the
problem, but I wasn't sure if this is safe coding.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=823





------- Additional Comments From dtucker at zip.com.au  2004-04-06 09:49 -------
link() on Linux returns EPERM in that case, which seems to be indistinguishable
from a vanilla permission error.  (OpenBSD returns EOPNOTSUPP, but the
sftp-server problem probably exists there too for filesystems with non-Unix
semantics.)

I guess if it link() fails because of permissions then rename() will too, so
it's probably as safe as the old code (ie prone to whatever races the old
code was).



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=823





------- Additional Comments From djm at mindrot.org  2004-04-06 10:26 -------
The semantics do differ: rename() will clobber the destination, whereas link()
will not. I'm not sure to what extent that this will matter, but I'm
sure there
would be consequences.

I'm not sure how to fix this, given that the Linux semantics don't give
us any
useful information. They should really to be fixed to return a "not
supported"
errno.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=823





------- Additional Comments From dtucker at zip.com.au  2004-04-06 11:02 -------
Well, http://www.ietf.org/internet-drafts/draft-ietf-secsh-filexfer-05.txt has
an extra field (compared to filexfer-02) "flags" for rename:

 'flags' is 0 or a combination of:

       SSH_FXP_RENAME_OVERWRITE  0x00000001
       SSH_FXP_RENAME_ATOMIC     0x00000002
       SSH_FXP_RENAME_NATIVE     0x00000004



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=823





------- Additional Comments From djm at mindrot.org  2004-04-06 11:13 -------
That won't help until both our sftp client and sftp-server support filexfer
v5,
which is a little tricky if one wants to remain backwards compatible. 

I have a few reservations about v5 which I'd like to see ironed out. Also
the
pace of change of the filexfer drafts has been relatively fast, so anything
implemented would likely bitrot. 

Personally, I won't be bothering to implement them until things settle down.
(Don't let that stop anyone else though)





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=823





------- Additional Comments From dtucker at zip.com.au  2004-04-06 11:34 -------
My point was that in earlier versions (it was introduced in v5) it's
unspecified, so for those versions sftp-server can do whatever the heck it likes
:-).

I've just been reading the draft and it seems like quite a lot of work to
implement, even without the backwards compatibility.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=823





------- Additional Comments From dtucker at zip.com.au  2004-04-06 12:03 -------
Created an attachment (id=596)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=596&action=view)
Make sftp rename fall back if fs doesn't support links (eg fat)

This fixes the problem on OpenBSD by falling back to stat+rename if the
filesystem doesn't support links.  Not sure what to do about it on Linux,
though (see djm's comment #2).



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=823

dtucker at zip.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |openbsd, patch





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=823





------- Additional Comments From dtucker at zip.com.au  2004-04-06 12:22 -------
Created an attachment (id=597)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=597&action=view)
Possible implementation for Linux

Maybe something like this (with the appropriate bits in configure plus
attachment #596) for Linux?

I don't think this would be any worse on Linux for filesystems with Unix
semantics.  You would only fall into the rename() block if the file exists but
you don't have perms.  If the file still exists at the time of the stat(),
nothing happens.  If it doesn't, the rename happens.

In particular, you can't have the case where a newly-created file is
clobbered,
because you can't get into the racy section unless you get the EPERM first.

Of course, on FAT, all bets are off.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=823

andreas at conectiva.com.br changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andreas at conectiva.com.br





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.