RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 668057 - [fix available] file locks are not created with gvfs-sftp volumes with OpenOffice.org/LibreOffice
Summary: [fix available] file locks are not created with gvfs-sftp volumes with OpenOf...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libreoffice
Version: 6.1
Hardware: Unspecified
OS: Unspecified
low
high
Target Milestone: rc
: ---
Assignee: Caolan McNamara
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 637248 671087
TreeView+ depends on / blocked
 
Reported: 2011-01-07 19:17 UTC by Matthew Mosesohn
Modified: 2018-11-14 15:42 UTC (History)
8 users (show)

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
Clone Of:
Environment:
Last Closed: 2012-06-20 12:52:51 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
proto-patch, might work (6.22 KB, patch)
2011-01-10 16:50 UTC, Caolan McNamara 		no flags Details | Diff
backport this (5.79 KB, patch)
2011-01-12 10:52 UTC, Caolan McNamara 		no flags Details | Diff
better patch (6.45 KB, patch)
2011-01-14 10:57 UTC, Caolan McNamara 		no flags Details | Diff
use server-side permissions when copying local tmp file to server (7.19 KB, patch)
2011-01-20 17:26 UTC, Caolan McNamara 		no flags Details | Diff
Show Obsolete (3) View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2012:0798 0 normal SHIPPED_LIVE new packages: libreoffice 2012-06-19 21:00:52 UTC

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
Note You need to log in before you can comment on or make changes to this bug.