Apache OpenOffice (AOO) Bugzilla – Issue 75446
Openoffice won't open files using sftp:// in read/write mode
Last modified: 2017-05-20 09:23:57 UTC
This bug is forwarded from Ubuntu Launchpad: https://launchpad.net/ubuntu/+source/openoffice.org/+bug/41985 Pop an openoffice document on a sftp:// 'share' under gnome, attempt to open. File will open in read-only mode, even if permissions are otherwise correct. A text-file in the same directory, will open in read-write mode with no problems in gedit, which eliminates gnome-vfs.
Created attachment 43737 [details] read-only check for gnomevfs
The attached file shows a section from OO.o source. It checks if the remote file has owner or group matches the uid/gid of the running Openoffice process (!) This is all just plain wrong: - Local and remote users/groups aren't necessarily matching. - Openoffice checks things which lay in the domain of libgnomevfs - Even if users/groups are in sync on local/remote system, there can be supplementary groups the user (on both sides) can be part of.
-> philippsadleder: Could you provide a patch for it?
Hi Andreas, can you have a look at this, please? Thanks, Matthias
-> pagalmes: Sorry, I cannot provide a patch at the moment. I'll maybe try to build up a patch for the issue, but for now I can only point to the code in gedit, which gets it right as far as I can tell. But I think people familiar with gnomevfs could fix this in short time. Thanks for your work, Philipp
-> philippsadleder: > But I think people familiar with gnomevfs could fix this in short time. if you know such guys, asking them to write a patch would help to solve the issue quickly. Thanks
I asked pbor on #gedit IRC channel for a comment on the issue: pbor: sadleder: yes, as you said those checks for uid and gid are totally bogus pbor: another difference is that gedit doesn't check at load, but on save pbor: and for saving we just save locally and transfer the file, so those kind of checks come for free pbor: in other word, we just try and if it fails we handle the exception gracefully sadleder: hmm, ok, where are files saved locally before transferring to remote? pbor: at the moment in tmp if I recall correctly pbor: with the propoer umask and stuff to protect privacy pbor: sadleder: also, did you check that you actually go past this condition: if (m_info.valid_fields & GNOME_VFS_FILE_INFO_FIELDS_PERMISSIONS) pbor: if that it is not met, do you default to writable or not writable? pbor: I seem to recall that ssh doesn't set that field pbor: so your problem may be that you default to not-writable in that case pbor: - in general I think that those kind of checks should be done lazily on save, not on load (think of the case when the perms change while the file is open), but that is a OO design decision
mmeeks: You are the original author ;-) - what do you think, please?
I think, that if there was a tested & working patch to review, then I would review it :-) but that the basic premise of returning some different value if we have no idea what the permissions are (ie. not read-only/void) is fine by me.
ABI->KSO: As discussed to you ...
.
At least the main part of the issue is fixed in Debian sid (2.2.1) and Ubuntu feisty (2.2.0). What doesn't work now is opening files via sftp:// that have only read permissions. OOo reports a "common error in the internet area" (translated back from German).
KSO->TKR: Please take care of this issue.
No time to fix this in 2.x time frame. => 3.0
Is this bug still expected to be fixed for OOo 3.0?
Yes, still scheduled for OOo 3.0.
I couldn't reproduce this behavior. Seems to work even with "read-only" documents. Is that only me? If I browse in a "sftp" environment with the OOo file dialog. I have noticed that OOo gets instable?! (error messages / crashes)
For now I will set the issue to OOo 3.1.
It's been a while since I looked into this but if I remember correctly OpenOffice.org tries to use the same uid/gid from the local system on the remote system which doesn't work in most cases.
I have duplicated this issue in Fedora 9 on both OOo 2.4 and 3.0 offered for info purposes, will continue to monitor this issue for a solution. Need one ASAP or a workaround as I use sftp extensively. Am willing to try possible solutions as they become available to verify working/not working.
No time to fix this in 3.1 time frame. => 3.2
I have been documenting the behavior in this thread: http://user.services.openoffice.org/en/forum/viewtopic.php?f=16&t=11176&start=10 The link is to page 2 of my documentation. The last couple of update posts leads me to believe that the problem may be in the way that nautilus is bringing up openoffice or possibly how openoffice handles what nautilus gives it when the the file is double clicked in nautilus.
This also occurs when opening files over NFS mounts if the ACL restricts write to a secondary group. Works fine using ACL that require primary group membership.
Sorry about that, but I cannot fix it for 3.2 -> New target 3.3
This also happens for me, using OOo310m11 (build 9399) on Ubuntu Hardy 8.04 LTS. It works when opening files, but fails when saving them, giving an "insufficient user permissions" error. BTW, I'm using SFTP shares: sftp://[...]. But it also happens when accessing directly from ~/.gvfs/[...] directory. All works fine when I open & save these documents (.odt, .doc, .txt...) with other applications, like Gedit. Any ideas? Are there any plans to correct this bug before 3.3? Thanks.
No, not before 3.3 but it is planned to fix it with 3.3
I have tried to get the access rights with passing the GNOME_VFS_FILE_INFO_GET_ACCESS_RIGHTS option to the 'gnome_vfs_get_file_info' call and then using the GNOME_VFS_PERM_ACCESS_WRITABLE permission flag to determine if the document is read only . But I haven't a clue why this doesn't work with sftp://. (fileInfo->valid_flags doesn't have the GNOME_VFS_FILE_INFO_FIELDS_ACCESS flag). If anyone has an idea please give me a hint. Otherwise i will change the behavior form eager permission check to open all documents in write mode and check permission on save to fix this issue. @rlfebrero: I cannot reproduce the behavior your described. Working with the ~/.gvfs/ directory works for me. Using sftp:// gives me read-only documents. Both on Ubuntu 9.04.
Fixed as described above. All documents will be open as writable if the ucp couldn't get permission information from gvfs for any reason. If the document is only read-only the user will get a "general internet error" (sorry for this error message) during save. Fix is committed in tkr26. Maybe someone want to try it out
Ok, I will try ASAP (which can be never). BTW, I was using Ubuntu Hardy (8.04) with OpenOffice at the following repository: deb http://ppa.launchpad.net/openoffice-pkgs/ubuntu hardy main
TKR->TM: Please verify as described above in cws tkr32.
Verified in CWS tkr32.