DO NOT REPLY [Bug 5520] New: Rsync cannot copy to a vfat partitionon kernel 2.6.25+ - Tools

This is a discussion on DO NOT REPLY [Bug 5520] New: Rsync cannot copy to a vfat partitionon kernel 2.6.25+ - Tools ; https://bugzilla.samba.org/show_bug.cgi?id=5520 Summary: Rsync cannot copy to a vfat partition on kernel 2.6.25+ Product: rsync Version: 3.0.3 Platform: All URL: https://bugzilla.redhat.com/show_bug.cgi?id=449080 OS/Version: Linux Status: NEW Severity: major Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy: piskozub@iopan.gda.pl QAContact: rsync-qa@samba.org This was reported by ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: DO NOT REPLY [Bug 5520] New: Rsync cannot copy to a vfat partitionon kernel 2.6.25+

  1. DO NOT REPLY [Bug 5520] New: Rsync cannot copy to a vfat partitionon kernel 2.6.25+

    https://bugzilla.samba.org/show_bug.cgi?id=5520

    Summary: Rsync cannot copy to a vfat partition on kernel 2.6.25+
    Product: rsync
    Version: 3.0.3
    Platform: All
    URL: https://bugzilla.redhat.com/show_bug.cgi?id=449080
    OS/Version: Linux
    Status: NEW
    Severity: major
    Priority: P3
    Component: core
    AssignedTo: wayned@samba.org
    ReportedBy: piskozub@iopan.gda.pl
    QAContact: rsync-qa@samba.org


    This was reported by me on the RedHat Bugzilla (URL given) and reclassified as
    a kernel bug. However, this seems to be caused by a conscious decision of the
    vfat Linux kernel developers and therefore may be easier to solve from the
    rsync end.

    In a nutshell: Rsync cannot now copy to a vfat partition even if the user is
    root (yes!). This is due to new and more strict vfat operations security model
    adopted in the kernel. When rsync tries to mkstemp it gets a "not permitted"
    error.

    This bug was discussed on LKML (the best URL is
    http://www.gossamer-threads.com/list.../kernel/927626) with n conclusions
    so far. However it is clear that:

    1) Kernel 2.6.25 (and newer) does not let "allows only acceptable chmod(), and
    if not acceptable, it returns -EPERM. Old one allows even if it can't store the
    disk inode."

    2) As Hirofumi Ogawa explained to me in an email:
    "rsync will try to set permission to 0700 or something. But, FAT can't
    store almost permissions to storage, because FAT doesn't have permission
    field on disk inode (FAT have permission field on only memory
    inode). So, chmod() returns -EPERM."

    3) It is not clear how and whether at all it will be solved in the kernel
    because as Pavel Machek put it: "So we have choice between security hole and
    regression...?"

    The question is: Can this be solved from the rsync end?


    --
    Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
    ------- You are receiving this mail because: -------
    You are the QA contact for the bug, or are watching the QA contact.
    --
    Please use reply-all for most replies to avoid omitting the mailing list.
    To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
    Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html


  2. DO NOT REPLY [Bug 5520] Rsync cannot copy to a vfat partition onLinux kernel 2.6.25+

    https://bugzilla.samba.org/show_bug.cgi?id=5520


    wayned@samba.org changed:

    What |Removed |Added
    ----------------------------------------------------------------------------
    Status|NEW |ASSIGNED




    ------- Comment #1 from wayned@samba.org 2008-06-14 13:13 CST -------
    I assume that the -EPERM error is at the kernel level, and the application gets
    a return of -1 with errno = EPERM. It would be much better to return errno =
    EINVAL so that the error could be easily distinguished from a real EPERM error
    where the user doesn't have permission to operate on the file. Since the
    kernel call is complaining about being unable to support the requested
    permissions, EINVAL seems like a much more logical error to me. But let's
    leave that aside for now.

    I assume it is the fchmod() function that is returning the error (sadly, the
    strace in the original bug report did not contain the process that was actually
    failing). If so, you can avoid the mkstemp failure by not asking rsync to
    preserve permissions (e.g. --no-p).

    So, is the issue that rsync is trying to create a mode 0600 file and the mount
    options are set to make the mount world-readable/writable? I'd be loath to
    make rsync retry the fchmod() call with 0666 unless the user asked for that
    explicitly. Or perhaps have an option to just skip the fchmod() on the temp
    file?

    Any no-option ideas that are safe? Perhaps test if the new temp file has bits
    set outside the umask, and if so, skip the fchmod()?

    You might also try changing your mount options to mount the media as a single
    user, which I would imagine would make a mode of 0600 acceptable to the kernel.


    --
    Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
    ------- You are receiving this mail because: -------
    You are the QA contact for the bug, or are watching the QA contact.
    --
    Please use reply-all for most replies to avoid omitting the mailing list.
    To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
    Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html


  3. DO NOT REPLY [Bug 5520] Rsync cannot copy to a vfat partition onLinux kernel 2.6.25+

    https://bugzilla.samba.org/show_bug.cgi?id=5520





    ------- Comment #2 from piskozub@iopan.gda.pl 2008-06-14 16:26 CST -------
    Changing the mount options and/or rsyncing as root did not help in my original
    tests. But I probably missed a thing with the options reporting they do not
    affect the problem (see below).

    I did more tests today under the newest Fedora 9 kernel
    (kernel-2.6.25.6-55.fc9).
    You are right about the options. This happens only with -p (or -a which is
    probably why I missed it before). I actually could successfully sync the vfat
    partition replacing -a with -rt (because I did not need the other components of
    -a on a FAT partition, anyway).

    This means there is a simple workaround but still either rsync or the kernel
    should be MHO modified to avoid the -p problem.


    --
    Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
    ------- You are receiving this mail because: -------
    You are the QA contact for the bug, or are watching the QA contact.
    --
    Please use reply-all for most replies to avoid omitting the mailing list.
    To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
    Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html


+ Reply to Thread