Mailing List Archive: [Bug 823] Rename fails on fat32 partitions

[Bug 823] Rename fails on fat32 partitions

bugzilla-daemon at mindrot

Mar 30, 2004, 12:49 AM

Post #1 of 10 (295 views)

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@mindrot.org
ReportedBy: iwish@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.

[Bug 823] Rename fails on fat32 partitions [ In reply to ]

bugzilla-daemon at mindrot

Apr 5, 2004, 3:49 PM

Post #2 of 10 (290 views)

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

------- Additional Comments From dtucker@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.

[Bug 823] Rename fails on fat32 partitions [ In reply to ]

bugzilla-daemon at mindrot

Apr 5, 2004, 4:26 PM

Post #3 of 10 (290 views)

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

------- Additional Comments From djm@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.

[Bug 823] Rename fails on fat32 partitions [ In reply to ]

bugzilla-daemon at mindrot

Apr 5, 2004, 5:02 PM

Post #4 of 10 (292 views)

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

------- Additional Comments From dtucker@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.

[Bug 823] Rename fails on fat32 partitions [ In reply to ]

bugzilla-daemon at mindrot

Apr 5, 2004, 5:13 PM

Post #5 of 10 (289 views)

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

------- Additional Comments From djm@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.

[Bug 823] Rename fails on fat32 partitions [ In reply to ]

bugzilla-daemon at mindrot

Apr 5, 2004, 5:34 PM

Post #6 of 10 (292 views)

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

------- Additional Comments From dtucker@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.

[Bug 823] Rename fails on fat32 partitions [ In reply to ]

bugzilla-daemon at mindrot

Apr 5, 2004, 6:03 PM

Post #7 of 10 (290 views)

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

------- Additional Comments From dtucker@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.

[Bug 823] Rename fails on fat32 partitions [ In reply to ]

bugzilla-daemon at mindrot

Apr 5, 2004, 6:03 PM

Post #8 of 10 (290 views)

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

dtucker@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.

[Bug 823] Rename fails on fat32 partitions [ In reply to ]

bugzilla-daemon at mindrot

Apr 5, 2004, 6:22 PM

Post #9 of 10 (290 views)

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

------- Additional Comments From dtucker@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.

[Bug 823] Rename fails on fat32 partitions [ In reply to ]

bugzilla-daemon at mindrot

Apr 6, 2004, 1:44 PM

Post #10 of 10 (290 views)

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

andreas@conectiva.com.br changed:

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

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