Bug 668057

Summary: [fix available] file locks are not created with gvfs-sftp volumes with OpenOffice.org/LibreOffice
Product: Red Hat Enterprise Linux 6 Reporter: Matthew Mosesohn <mmosesoh>
Component: libreofficeAssignee: Caolan McNamara <caolanm>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: high Docs Contact:
Priority: low    
Version: 6.1CC: caolanm, cmeadors, dtardon, msanders, ofourdan, syeghiay, tpelka, vsharapo
Target Milestone: rcKeywords: ZStream
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: libreoffice-3.4.5.2-8.el6 Doc Type: Bug Fix
Doc Text:
Cause: Unable to create lock files on sftp file shares Consequence: Multiple users editing the same document shared out on certain network schemes are unaware that the document is being edited by someone else Fix: Extend the list of known protocols which can support file locking to include sftp Result: Multiple users editing a document shared over sftp will be warned if someone else is also editing that document
 Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-20 12:52:51 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 637248, 671087    
Attachments:
Description Flags
proto-patch, might work
none
backport this
none
better patch
none
use server-side permissions when copying local tmp file to server none

Description Matthew Mosesohn 2011-01-07 19:17:42 UTC 
Description of problem:

This problem affects a large # of people with file shares mounted with SFTP via gvfs.  Normally, when you open a file in OpenOffice.org, the application creates a lock file named .~lock.$filename.ods#.   

Version-Release number of selected component (if applicable):
openoffice.org-core-3.2.1-19.6.el6.x86_64
gvfs-1.4.3-9.el6.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Create a gvfs-sftp connection via Nautilus.  File -> Connect to Server -> (fill in details for a remote machine you have SSH access to)
2. Launch OpenOffice.org, and create a new Spreadsheet
3. Save the file as test.ods on the remote connection
4. SSH to the remote machine and type "ls -la *test*"
  
Actual results:
The lock file is never created.
If another user tries to access this file, he or she is never presented with a warning that this file is opened by another user.  Data loss can easily result.

Expected results:
There should be a warning presented to the user.


Additional info:
This appears to affect Fedora 14's OpenOffice.org version 3.3.0-17.2.fc14 as well (gvfs 1.6.6-1.fc14)

The only alternatives are (insecure) NFS, or fuse-sshfs which is currently broken, depending on 625064, but gvfs is most ideal since it can be done without any manual configuration on the command line.
Comment 2 Matthew Mosesohn 2011-01-07 19:42:02 UTC 
Additionally, if there is a lock file present, OpenOffice.org appears to ignore it when mounting over gvfs-sftp, and opens the file for editing (possible data loss)
Comment 3 RHEL Program Management 2011-01-07 19:48:36 UTC 
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.
Comment 4 Caolan McNamara 2011-01-10 12:36:55 UTC 
Locks are only created for file:/// urls not sftp:// ones. I suppose we can extend this for other protocols, sftp anyway.
Comment 10 Caolan McNamara 2011-01-10 16:50:03 UTC 
Created attachment 472644 [details]
proto-patch, might work
Comment 11 Matthew Mosesohn 2011-01-10 18:28:02 UTC 
Caolan,

Against what version of OpenOffice.org is this?  I tried to patch the latest RHEL6 SRPM openoffice.org-core-3.2.1-19.6.el6.x86_64.rpm, and many of these patches fail.
Comment 12 Caolan McNamara 2011-01-10 20:37:06 UTC 
Is against head of course. I'll fiddle with a backport tomorrow and stick it here then.
Comment 13 Caolan McNamara 2011-01-12 10:52:33 UTC 
Created attachment 472995 [details]
backport this
Comment 14 Caolan McNamara 2011-01-14 10:57:42 UTC 
Created attachment 473500 [details]
better patch
Comment 16 Matthew Mosesohn 2011-01-14 20:25:37 UTC 
Confirmed.  This creates the lock files properly for gvfs-sftp volumes.  As a bonus, an unpatched OpenOffice 3.2.1 will identify locked files.  I commend your efforts!
Comment 22 Matthew Mosesohn 2011-01-20 14:26:56 UTC 
This patch contains a regression that makes this problem worse.

If you write a new file to a gvfs-sftp volume, it writes with mask 0600 and
ignores setgid permission bit on a folder.

Steps to reproduce:
Create a folder on a server with permissions 2770
Connect via SFTP to this server
Write a new file inside of this folder

The resulting file has permissions 0600, but should have 0660

Please don't go forward with pushing this fix until this regression can be
fixed.
Comment 23 Caolan McNamara 2011-01-20 15:01:44 UTC 
Hmm, that's definitely odd.
Comment 24 David Tardon 2011-01-20 17:08:24 UTC 
The new file has perms 0600 because we just copy a file that has been created locally in /tmp with perms 0600 using gio_file_copy. (And the unpatched version behaves in the same way, so it is not a regression .-)
Comment 25 Matthew Mosesohn 2011-01-20 17:24:29 UTC 
David,

I hate to disagree with you, but I have a freshly installed RHEL 6 system that has openoffice version 3.2.1-19.6.el6.x86_64 (not patched), and I did the following steps:
1) Connect to the same server that I can reproduce this bug on
2) Create a new spreadsheet with OpenOffice Calc
3) type the word test in 20 random cells 
4) File -> Save
5) browse to the mounted sftp volume
6) save with a new filename
7) SSH in and look at file permissions.  The file obtains the proper permissions

I repeated this process 3 times with both patched and unpatched systems and the unpatched system never wrote a file with permissions 0600.

I did notice that if you have this scenario, the file written is fine with proper permissions:
1) Create a new file
2) Save it locally
3) Save it to the SFTP volume

Would debugging output help you with this effort?
Comment 26 Caolan McNamara 2011-01-20 17:26:50 UTC 
Created attachment 474500 [details]
use server-side permissions when copying local tmp file to server

fair enough, this does the trick
Comment 27 Matthew Mosesohn 2011-01-20 22:50:52 UTC 
Confirmed.  This patch works.  I have verified that this patch does not have the file permission issues that the previous one did.
Comment 41 Caolan McNamara 2012-05-01 09:39:52 UTC 
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause: Unable to create lock files on sftp file shares

Consequence: Multiple users editing the same document shared out on certain network schemes are unaware that the document is being edited by someone else

Fix: Extend the list of known protocols which can support file locking to include sftp

Result: Multiple users editing a document shared over sftp will be warned if someone else is also editing that document
Comment 43 errata-xmlrpc 2012-06-20 12:52:51 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2012-0798.html