Issue 75446 - Openoffice won't open files using sftp:// in read/write mode
Summary: Openoffice won't open files using sftp:// in read/write mode
Status: CLOSED FIXED
Alias: None
Product: ucb
Classification: Code
Component: code (show other issues)
Version: OOo 2.2 RC2
Hardware: All Linux, all
: P3 Trivial with 9 votes (vote)
Target Milestone: OOo 3.3
Assignee: thorsten.martens
QA Contact: issues@ucb
URL:
Keywords:
Depends on:
Blocks: 81913
  Show dependency tree
 
Reported: 2007-03-16 10:03 UTC by philippsadleder
Modified: 2017-05-20 09:23 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
read-only check for gnomevfs (1.06 KB, text/plain)
2007-03-16 10:06 UTC, philippsadleder
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description philippsadleder 2007-03-16 10:03:21 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.
Comment 1 philippsadleder 2007-03-16 10:06:36 UTC
Created attachment 43737 [details]
read-only check for gnomevfs
Comment 2 philippsadleder 2007-03-16 10:07:21 UTC
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.
Comment 3 pagalmes.lists 2007-03-17 12:15:05 UTC
-> philippsadleder: Could you provide a patch for it?
Comment 4 matthias.huetsch 2007-03-19 16:11:19 UTC
Hi Andreas,

can you have a look at this, please?

Thanks,
Matthias
Comment 5 philippsadleder 2007-03-20 09:10:43 UTC
-> 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
Comment 6 pagalmes.lists 2007-03-20 09:46:01 UTC
-> 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
Comment 7 philippsadleder 2007-03-21 09:54:37 UTC
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
Comment 8 kendy 2007-03-30 12:41:07 UTC
mmeeks: You are the original author ;-) - what do you think, please?
Comment 9 mmeeks 2007-04-02 11:04:02 UTC
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.
Comment 10 andreas.bille 2007-04-03 15:14:45 UTC
ABI->KSO: As discussed to you ...
Comment 11 kai.sommerfeld 2007-04-04 16:23:04 UTC
.
Comment 12 philippsadleder 2007-06-18 11:26:33 UTC
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).
Comment 13 kai.sommerfeld 2007-08-15 12:44:11 UTC
KSO->TKR: Please take care of this issue.
Comment 14 tkr 2007-08-20 09:55:45 UTC
.
Comment 15 kai.sommerfeld 2007-11-22 15:32:29 UTC
No time to fix this in 2.x time frame. => 3.0
Comment 16 ccheney 2008-04-25 20:09:13 UTC
Is this bug still expected to be fixed for OOo 3.0?
Comment 17 tkr 2008-04-28 08:19:25 UTC
Yes, still scheduled for OOo 3.0.
Comment 18 tkr 2008-05-27 15:01:43 UTC
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)
Comment 19 tkr 2008-06-06 13:53:50 UTC
For now I will set the issue to OOo 3.1.

Comment 20 ccheney 2008-10-17 20:06:44 UTC
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.
Comment 21 netmastr 2008-11-05 22:57:40 UTC
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.
Comment 22 tkr 2008-12-09 15:58:10 UTC
No time to fix this in 3.1 time frame. => 3.2
Comment 23 netmastr 2009-02-26 20:13:41 UTC
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. 
Comment 24 gdiebel 2009-03-03 19:57:51 UTC
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.
Comment 25 tkr 2009-09-04 12:38:38 UTC
Sorry about that, but I cannot fix it for 3.2 -> New target 3.3
Comment 26 rlfebrero 2009-09-24 09:35:41 UTC
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.
Comment 27 tkr 2009-09-29 09:10:48 UTC
No, not before 3.3 but it is planned to fix it with 3.3
Comment 28 tkr 2009-10-01 13:56:39 UTC
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.




Comment 29 tkr 2009-10-07 07:37:23 UTC
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 

Comment 30 rlfebrero 2009-10-07 10:05:31 UTC
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
Comment 31 tkr 2009-12-07 10:58:22 UTC
TKR->TM: Please verify as described above in cws tkr32.
Comment 32 stefan.baltzer 2010-02-08 11:26:55 UTC
Verified in CWS tkr32.