Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
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
DescriptionMatthew 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.
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 3RHEL 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 11Matthew 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 16Matthew 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 22Matthew 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.
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 25Matthew 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?
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
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