DO NOT REPLY [Bug 5027] New: Perms in do_mkstemp are not always
valid
samba-bugs at samba.org
samba-bugs at samba.org
Sat Oct 20 02:00:35 GMT 2007
https://bugzilla.samba.org/show_bug.cgi?id=5027
Summary: Perms in do_mkstemp are not always valid
Product: rsync
Version: 2.6.9
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P3
Component: core
AssignedTo: wayned at samba.org
ReportedBy: cmadams at hiwaay.net
QAContact: rsync-qa at samba.org
I'm trying to rsync (with -a to preserve permissions) to a mount point on an
NFS server, and it fails when copying a file that is read-only. The problem is
that do_mkstemp creates the temp file with the desired user permissions (either
with open() or with fchmod().
SUSv3 says that the affect of chmod()/fchmod() on existing open file
descriptors is implemtation defined; it also says:
Any file descriptors currently open by any process on the file could
possibly become invalid if the mode of the file is changed to a value which
would deny access to that process. One situation where this could occur is
on a stateless file system. This behavior will not occur in a conforming
environment.
I guess I have a non-conforming environment (I'm talking to a unfs3 server).
If I remove HAVE_FCHMOD, it still doesn't work, because the call to open()
includes the read-only permissions as well (a case I don't really see
referenced in SUSv3 right off).
The following patch makes sure that the user always has write permission to the
temp file:
diff -urN rsync-2.6.9-dist/syscall.c rsync-2.6.9/syscall.c
--- rsync-2.6.9-dist/syscall.c 2007-10-19 20:49:29.000000000 -0500
+++ rsync-2.6.9/syscall.c 2007-10-19 20:53:02.000000000 -0500
@@ -190,6 +190,7 @@
{
RETURN_ERROR_IF(dry_run, 0);
RETURN_ERROR_IF(read_only, EROFS);
+ perms |= S_IWUSR;
#if defined HAVE_SECURE_MKSTEMP && defined HAVE_FCHMOD && (!defined
HAVE_OPEN64 || defined HAVE_MKSTEMP64)
{
--
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.
More information about the rsync
mailing list