libreoffice cannot open a document not within $HOME

Bug #1751005 reported by Mike Cornelison on 2018-02-22
170
This bug affects 29 people
Affects Status Importance Assigned to Milestone
libreoffice (Ubuntu)
Critical
Olivier Tilloy

Bug Description

Starting with today's update to LibreOffice 5.4.5.1 40m0(Build:1), files not within the user $HOME directory cannot be opened. This has nothing to do with ownership or permissions - the target document is owned by the user with full permissions. Moving the file to ~/Desktop allows it to be opened normally.

Error message in popup window:
  Access to /home2/mico/documents/personal/2018 lists.ods was denied.

Error message when launched from terminal:
$: localc "2018 lists.ods"
javaldx: Could not find a Java Runtime Environment!
Please ensure that a JVM and the package libreoffice-java-common is installed.
If it is already installed then try removing ~/.libreoffice/3/user/config/javasettings_Linux_*.xml
Warning: failed to read path from javaldx

The file mentioned in the error message does not exist.
I removed the corresponding file under ~/.libreoffice/4/ but that makes no difference.

This but started in Ubuntu 18.04 (alpha) around Feb. 15, and with today's update (Feb. 22) it appeared in Ubuntu 17.10.

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: libreoffice-core 1:5.4.5-0ubuntu0.17.10.1
ProcVersionSignature: Ubuntu 4.13.0-36.40-generic 4.13.13
Uname: Linux 4.13.0-36-generic x86_64
ApportVersion: 2.20.7-0ubuntu3.7
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Thu Feb 22 09:35:49 2018
InstallationDate: Installed on 2018-01-27 (25 days ago)
InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20180105.1)
SourcePackage: libreoffice
UpgradeStatus: No upgrade log present (probably fresh install)

Mike Cornelison (kornelix-i) wrote :
Jan Wester (j-vester) wrote :

I get the problem with system complaining about permissions on .config/libreoffice/4 since latest libreoffice upgrade on ubuntu 17.10. This problem has arrived on 3 installs up to now. Only solution I have found is to add the ppa on libreoffice and upgrade it to the latest libreoffice 6. Then it starts without any problems. Which proves to me that this is NOT a correct error description from libreoffice. The problem is not about permissions at all.

Olivier Tilloy (osomon) wrote :

The error message about ~/.libreoffice/{3,4}/user/config/javasettings_Linux_*.xml is unrelated, it is simply telling you libreoffice cannot find a JRE (but it will work fine without it, for the most part).

What you're seeing is apparmor confinement finally working as intended. The package had been shipping apparmor profiles for some time, but they were not functional, and they have been fixed.
Those profiles allow reading/writing office documents in $HOME, /mnt and /media (that excludes /home2/).

Can you try running the following command in a terminal, and confirm that this "fixes" your issue:

    sudo apparmor_parser -R /etc/apparmor.d/usr.lib.libreoffice.program.*

Jan Wester (j-vester) wrote :

olivier: i read your answer and is a bit confused. why does upgrading to libreoffice 6 not suffer from this problem?

Olivier Tilloy (osomon) wrote :

Jan, if you installed LO 6 from the PPA, it might not have all the required fixes for the apparmor profiles. But the version in the archive (currently in bionic-proposed) will have them.

Can you please confirm that the command I suggested in comment #3 resolves your issue (that's temporary until the next reboot).

Jan Wester (j-vester) wrote :

i have to downgrade libreoffice first i guess.........have no installation left with libreoffice 5 for the moment

Jan Wester (j-vester) wrote :

okay. looks promising.

i did this:

sudo ppa-purge ppa:libreoffice/ppa. now libreoffice 5 installed again and gives the error.

sudo apparmor_parser -R /etc/apparmor.d/usr.lib.libreoffice.program.* libreoffice starts up and seems to be working..............

Jan Wester (j-vester) wrote :

as you said: this is temporary. how do i make it permanent?

Jan Wester (j-vester) wrote :

think i understand now. i guess what the apparmor_parser command does is to temporarily disable the profiles for libreoffice.

and disable it permanently does not sound like a good idea. i guess.

so: i guess the solution is to get a new version of libreoffice. right?

Olivier Tilloy (osomon) wrote :

No, that's not a solution, because as soon as libreoffice 6 is in the ubuntu archive it will have the working apparmor profiles. If you want to disable the apparmor profiles permanently, you can do the following:

    sudo ln -s /etc/apparmor.d/usr.lib.libreoffice.program.* /etc/apparmor.d/disable/

I'm going to mark this bug invalid as the apparmor profiles are working as expected, but your setup (with a /home2 mount point) is rather exotic.

Changed in libreoffice (Ubuntu):
status: New → Invalid
Jan Wester (j-vester) wrote :

setup is actually like this:

user data is on an extra disk. that disk is mounted in fstab

UUID=7707da2d-a878-40db-9311-f53ed74c821f /export ext4 defaults 0 1

then soft links for /home/janw to /export/home/janw is done.

yes that is not standard i know......

but it makes reinstallations of OS much easier..........with user data intact

Nick Butlin (nicholasbutlin) wrote :

Hi, I have the same issue - with a relatively new vanilla install of 17.10 - the last upgrade broke the ability to load the file with the same permission denied

disabling the apparmor profile fixed the issue

Olivier Tilloy (osomon) wrote :

@Jan: if you mount your external disk under /mnt or /media (and change your symlinks to point there), that should allow you to use libreoffice confined, which IMHO is better than permanently disabling the apparmor profiles.

@Nick: the files you're attempting to open are neither in your home directory, nor under /mnt or /media, right?

 After getting over the confusion caused by your example, and inputting
the entire command on one line, it did solve the problem. Thanks. The
diagnostic could have been less cryptic.

On 22.02.2018 12:06, Olivier Tilloy wrote:

> The error message about
> ~/.libreoffice/{3,4}/user/config/javasettings_Linux_*.xml is unrelated,
> it is simply telling you libreoffice cannot find a JRE (but it will work
> fine without it, for the most part).
>
> What you're seeing is apparmor confinement finally working as intended. The package had been shipping apparmor profiles for some time, but they were not functional, and they have been fixed.
> Those profiles allow reading/writing office documents in $HOME, /mnt and /media (that excludes /home2/).
>
> Can you try running the following command in a terminal, and confirm
> that this "fixes" your issue:
>
> sudo apparmor_parser -R
> /etc/apparmor.d/usr.lib.libreoffice.program.*
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1751005 [1]
>
> Title:
> libreoffice cannot open a document not within $HOME
>
> Status in libreoffice package in Ubuntu:
> New
>
> Bug description:
> Starting with today's update to LibreOffice 5.4.5.1 40m0(Build:1),
> files not within the user $HOME directory cannot be opened. This has
> nothing to do with ownership or permissions - the target document is
> owned by the user with full permissions. Moving the file to ~/Desktop
> allows it to be opened normally.
>
> Error message in popup window:
> Access to /home2/mico/documents/personal/2018 lists.ods was denied.
>
> Error message when launched from terminal:
> $: localc "2018 lists.ods"
> javaldx: Could not find a Java Runtime Environment!
> Please ensure that a JVM and the package libreoffice-java-common is installed.
> If it is already installed then try removing ~/.libreoffice/3/user/config/javasettings_Linux_*.xml
> Warning: failed to read path from javaldx
>
> The file mentioned in the error message does not exist.
> I removed the corresponding file under ~/.libreoffice/4/ but that makes no difference.
>
> This but started in Ubuntu 18.04 (alpha) around Feb. 15, and with
> today's update (Feb. 22) it appeared in Ubuntu 17.10.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 17.10
> Package: libreoffice-core 1:5.4.5-0ubuntu0.17.10.1
> ProcVersionSignature: Ubuntu 4.13.0-36.40-generic 4.13.13
> Uname: Linux 4.13.0-36-generic x86_64
> ApportVersion: 2.20.7-0ubuntu3.7
> Architecture: amd64
> CurrentDesktop: ubuntu:GNOME
> Date: Thu Feb 22 09:35:49 2018
> InstallationDate: Installed on 2018-01-27 (25 days ago)
> InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20180105.1)
> SourcePackage: libreoffice
> UpgradeStatus: No upgrade log present (probably fresh install)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1751005/+subscriptions [2]

Links:
------
[1] https://bugs.launchpad.net/bugs/1751005
[2]
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1751005/+subscriptions

Mike Cornelison (kornelix-i) wrote :

 Exotic?
I am a developer and run several different flavors of Linux for testing.
I have done this for years for files accessible to all flavors.

If the file ownership and permissions are OK, I think I should be able
to access them by default. Apparmor seems to be configured to
another default - deny access to my owned files if not under $HOME.
Is this a good default?

On 22.02.2018 13:50, Olivier Tilloy wrote:

> No, that's not a solution, because as soon as libreoffice 6 is in the
> ubuntu archive it will have the working apparmor profiles. If you want
> to disable the apparmor profiles permanently, you can do the following:
>
> sudo ln -s /etc/apparmor.d/usr.lib.libreoffice.program.*
> /etc/apparmor.d/disable/
>
> I'm going to mark this bug invalid as the apparmor profiles are working
> as expected, but your setup (with a /home2 mount point) is rather
> exotic.
>
> ** Changed in: libreoffice (Ubuntu)
> Status: New => Invalid
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1751005 [1]
>
> Title:
> libreoffice cannot open a document not within $HOME
>
> Status in libreoffice package in Ubuntu:
> Invalid
>
> Bug description:
> Starting with today's update to LibreOffice 5.4.5.1 40m0(Build:1),
> files not within the user $HOME directory cannot be opened. This has
> nothing to do with ownership or permissions - the target document is
> owned by the user with full permissions. Moving the file to ~/Desktop
> allows it to be opened normally.
>
> Error message in popup window:
> Access to /home2/mico/documents/personal/2018 lists.ods was denied.
>
> Error message when launched from terminal:
> $: localc "2018 lists.ods"
> javaldx: Could not find a Java Runtime Environment!
> Please ensure that a JVM and the package libreoffice-java-common is installed.
> If it is already installed then try removing ~/.libreoffice/3/user/config/javasettings_Linux_*.xml
> Warning: failed to read path from javaldx
>
> The file mentioned in the error message does not exist.
> I removed the corresponding file under ~/.libreoffice/4/ but that makes no difference.
>
> This but started in Ubuntu 18.04 (alpha) around Feb. 15, and with
> today's update (Feb. 22) it appeared in Ubuntu 17.10.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 17.10
> Package: libreoffice-core 1:5.4.5-0ubuntu0.17.10.1
> ProcVersionSignature: Ubuntu 4.13.0-36.40-generic 4.13.13
> Uname: Linux 4.13.0-36-generic x86_64
> ApportVersion: 2.20.7-0ubuntu3.7
> Architecture: amd64
> CurrentDesktop: ubuntu:GNOME
> Date: Thu Feb 22 09:35:49 2018
> InstallationDate: Installed on 2018-01-27 (25 days ago)
> InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20180105.1)
> SourcePackage: libreoffice
> UpgradeStatus: No upgrade log present (probably fresh install)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1751005/+subscriptions [2]

Links:
------
[1] https://bugs.launchpad.net/bugs/1751005
[2]
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1751005/+subscriptions

Olivier Tilloy (osomon) wrote :

> deny access to my owned files if not under $HOME.
> Is this a good default?

That's arguable of course. The expectation is that a vast majority of users will have a default setup where they store their documents under $HOME/, and for those the confinement provided by apparmor will be useful and won't get in the way.

This can be discussed, of course, so I'm going to change the status of this bug so the discussion can continue here. Please share compelling arguments here.

Changed in libreoffice (Ubuntu):
status: Invalid → Opinion
David Ing (divirtual) wrote :

I have just run upgrades, and am now at LibreOffice 5.4.5.1 on Kubuntu 17.10 . I found this thread because I had the "access was denied" issue.

My Thinkpad has original Windows 7 disk (where data is obviously stored on NTFS), and a mSATA on which I have a triple boot install (i.e. Kubuntu 17.10, Ubuntu 17.10 and Deepin Linux). On this "never fail" configuration, I should be able to invoke LibreOffice on any of the three Linux versions, or from Windows 7 (which I practically never do).

I have now run:

  sudo ln -s /etc/apparmor.d/usr.lib.libreoffice.program.* /etc/apparmor.d/disable/

... so LibreOffice works.

So, I haven't stored my documents under $HOME/ since 2009, and have used similar configurations running back to Ubuntu 9.04 and Windows XP and multiboot.

I am not a developer, and would describe myself as a "power user". I don't really understand apparmor, so I see this new change as something that could potentially disrupt any user who has multiple partitions on his or her computer.

Jan Wester (j-vester) wrote :

actually to avoid all of this:

sudo add-apt-repository ppa:libreoffice/ppa
sudo apt-get update
sudo apt-get upgrade

libreoffice starts without any tweaks and you are running the latest and greatest

Rico Tzschichholz (ricotz) wrote :

Eventually those apparmor changes will hit the backported PPA builds too.

Pankaj (ponkoj) wrote :

I was running into the same issue after the latest upgrade of 17.10 and libreoffice, and I tried a couple of things that have both failed. I have my libreoffice files sitting on FAT filesystem that I mount in fstab. Earlier I was mounting it at /data which I changed to /mnt/data. Yet I am unable to open my files (now under /mnt/data) in libreoffice. I also tried another trick of soft linking my Documents folder under /mnt/data to ~/Documents, and when I navigate via ~/Documents to open a file in libreoffice it gives the same access denied problem.

_Tof_ (ctariel) wrote :

Same issue here. My documents are on a NFS share on /media/commun/ .

Assuming that all documents are in /home is kind of stupid... What about all the companies that use shares (NFS or others...) ??

I solved my problem with the worst answer : stop and disable apparmor. Security without usability is a nonsense.

Sam Van den Eynde (samvde) wrote :

First a question for clarity: is this apparmor issue related to having libreoffice installed as a snap, or is this native to the archive version as well?

Second: I honestly can't grasp these kind of policy changes are rolled out without having the slightest idea on what impact this might cause on the installed base (which, as is clearly shown with the recent discussion on capturing data during installation, is a given fact). I use ZFS for my Documents, others might have a btrfs subvol, a separate filesystem, data on a NAS, or removable storage. This just breaks because we did apt-get upgrade on a current stable release of Ubuntu (yet we won't get LO6 on Xenial or Artful). This to me seems unacceptable and annoying to say the least.

If confinement has become a must-have, a decent file access interface that allows the user to provide access (as we do on phones) is a must-have. At least make sure the error is captured properly so we know what to do.

I'm experiencing the same issue with files mounted under /mnt/user/sshfs/user@server/home/user.... where user is the username of the individual and server is the server they are accessing. This means /mnt is also affected.

Removing the apparmor rules resolves the issue.

I have to say I agree with the others here that these rules are inappropriate. What about if an application came with an office document as part of its documentation?

Olivier Tilloy (osomon) wrote :

There are enough real use cases that got broken that this warrants a SRU to disable the apparmor profiles by default. Thank you for the feedback everyone, I'm working on that, expect another update as soon as possible. In the meantime, comment #10 explains how to disable the profiles yourself.

Changed in libreoffice (Ubuntu):
status: Opinion → Confirmed
importance: Undecided → Critical
Olivier Tilloy (osomon) on 2018-02-23
Changed in libreoffice (Ubuntu):
assignee: nobody → Olivier Tilloy (osomon)
status: Confirmed → In Progress
Olivier Tilloy (osomon) wrote :
Changed in libreoffice (Ubuntu):
status: In Progress → Fix Committed
Seth Arnold (seth-arnold) wrote :

As more applications get AppArmor profiles, this may come up more frequently.

Installations with "home directories" not under /home/ may want to install AppArmor alias rules so that user-oriented tools with profiles can function as desired. The usual place to write them is in /etc/apparmor.d/tunables/alias ; add a line like:

alias /home/ -> /home2/

or

alias /home/ -> /export/home/

as needed.

Thanks

sandeep (sandeepbhardwaj01) wrote :

I am also facing the same issue.

I am using Ubuntu 17.10 as my daily driver. I have created a separate partition like home for storage /data of ext4 type.

Today, after updated my system using apt dist-upgrade. I am unable to access all my documents from /data partition.

Mike Cornelison (kornelix-i) wrote :

 edit /etc/apparmor.d/tunables/alias
add the line: alias /home/ -> /data/

On 24.02.2018 10:10, sandeep wrote:

> I am also facing the same issue.
>
> I am using Ubuntu 17.10 as my daily driver. I have created a separate
> partition like home for storage /data of ext4 type.
>
> Today, after updated my system using apt dist-upgrade. I am unable to
> access all my documents from /data partition.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1751005 [1]
>
> Title:
> libreoffice cannot open a document not within $HOME
>
> Status in libreoffice package in Ubuntu:
> Fix Committed
>
> Bug description:
> Starting with today's update to LibreOffice 5.4.5.1 40m0(Build:1),
> files not within the user $HOME directory cannot be opened. This has
> nothing to do with ownership or permissions - the target document is
> owned by the user with full permissions. Moving the file to ~/Desktop
> allows it to be opened normally.
>
> Error message in popup window:
> Access to /home2/mico/documents/personal/2018 lists.ods was denied.
>
> Error message when launched from terminal:
> $: localc "2018 lists.ods"
> javaldx: Could not find a Java Runtime Environment!
> Please ensure that a JVM and the package libreoffice-java-common is installed.
> If it is already installed then try removing ~/.libreoffice/3/user/config/javasettings_Linux_*.xml
> Warning: failed to read path from javaldx
>
> The file mentioned in the error message does not exist.
> I removed the corresponding file under ~/.libreoffice/4/ but that makes no difference.
>
> This but started in Ubuntu 18.04 (alpha) around Feb. 15, and with
> today's update (Feb. 22) it appeared in Ubuntu 17.10.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 17.10
> Package: libreoffice-core 1:5.4.5-0ubuntu0.17.10.1
> ProcVersionSignature: Ubuntu 4.13.0-36.40-generic 4.13.13
> Uname: Linux 4.13.0-36-generic x86_64
> ApportVersion: 2.20.7-0ubuntu3.7
> Architecture: amd64
> CurrentDesktop: ubuntu:GNOME
> Date: Thu Feb 22 09:35:49 2018
> InstallationDate: Installed on 2018-01-27 (25 days ago)
> InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20180105.1)
> SourcePackage: libreoffice
> UpgradeStatus: No upgrade log present (probably fresh install)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1751005/+subscriptions [2]

Links:
------
[1] https://bugs.launchpad.net/bugs/1751005
[2]
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1751005/+subscriptions

Sam Van den Eynde (samvde) wrote :

If AppArmor configuration is needed for mounted directories, I think we need better information pushed to the users. If you say "add all your mountpoints with user files need to be in file X" I am fine with that. I just need to know.

Goes for snaps as well.

And I still think AppArmor provides fake security here. Files I own should be accessible. Now people will just start putting the files in another location to work around it. But that's just an opinion of course.

BertN45 (bertnijhof) wrote :

I hate these type of surprises, caused by badly designed and/or published improvements. The professional way to introduce those changes, is enabling the new intrusive function in the settings function of the program introducing that change.

I store all my files in the Virtualbox Shared Folders on a separate partition, because they are in principle accessible by all my virtual machines, who need them and I have VMs for:
- the normal office work
- banking and other financial apps
- to try out new apps
- windows for compatibility with old files
- to try-out alpha and beta releases of the OSes

I avoid the use of the home folder for documents, since it is a dirty mix between computer settings and documents. I only use Home for my local settings and store my document in a separate set of folders on a separate partition, not influenced by any OS changes.

I do not intend to change that set up. The Vbox shared folder files are owned by the root and I could get read and write access, by becoming a member of the vboxsf group. I do not intend to change all my "/etc/apparmor.d/tunables/alias" files in my VMs. Probably I will simply upgrade to LibreOffice 6, not having any access problem yet or I use Microsoft Office again in my Windows VM.

I have been in IT since 1969, but I have no clue what you hope to achieve nor how it could improve my situation.

Olivier Tilloy (osomon) wrote :

To everyone affected, please read again comment #24. An update is being prepared that will disable the apparmor profiles by default, effectively reverting to the old behaviour.

Enabling the profiles by default on upgrade was not intended, it's a human mistake.

BertN45 (bertnijhof) wrote :

OK, but where can I find, what the purpose is of this functionality? How could it improve my security? Do you have any reading material?

Ads20000 (ads20000) wrote :

BertN45 you can read this: https://wiki.ubuntu.com/AppArmor
As I understand it, an AppArmor profile on a program restricts what it can do to your computer, whereas without AppArmor or something similar to it, a program will have unrestricted access to your computer (except for what requires root). Do correct me if I'm wrong Olivier...

If you want this security back then you can install the LibreOffice snap and remove the LibreOffice Deb with `snap install libreoffice ; sudo apt remove libreoffice* ; sudo apt autoremove` but be warned that the LibreOffice snap has a number of bugs that don't exist in the Deb ( see here: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bugs?field.tag=snap )

BertN45 (bertnijhof) wrote :

OK. Thank you ads20000. I think, it really complicates the system for a home user. I'm completely happy with the restrictions per user. I know many home users, who even run into problems with that.

At the moment I have some VMs running LibreOffice 5.1 and 6.0 and those have no AppArmor issues. For the moment I use those LibreOffice versions.

jth (jth) wrote :

Hi
Unable to create or read document files in normal $HOME /home/userid/
Both in Artful and Bionic (1:5.4.5-0ubuntu0.17.10.1)

What a fail. Please never try that again.

--
Johan Thelmén

Navid Ord (naver7) wrote :

Hi,
I cannot read LibreOffice docs under /home/$USER/ in Artful either.
I hope it's fixed, though in the meanwhile, shall we disable the apparmor profile?

Sam Van den Eynde (samvde) wrote :

I have the libreoffice snap installed using classic confinement, yet I seem to have this issue. By comparison the Atom snap works as expected. Is the libreoffice snap version impacted by this as well?

Daniel (hackie) wrote :

Same problem here. Since installing 1:5.4.5-0ubuntu0.17.10.1.

My files are located in /daten/, where I have a complex structure with multiple volumes, which is identical over all my machines and never made any problems since 15 years.

If this is not ok anymore, because it's not LSB, this rule should affect _all_ applications, like inkscape, gimp, gedit, audacity, firefox, eclipse, etc. But then there will always be complains. Only making one application more restricted than others will result in bug reports like this here (for a good reason, I think)

holiday (stephenboston) on 2018-02-27
Changed in libreoffice (Ubuntu):
status: Fix Committed → Fix Released
David Stewart (dlpastewart-5) wrote :

I Just did an update of Ubuntu 17.10 and Libreoffice6 and still have the same problem with access denied on the windows partition of my hard disk. In Ubuntu Home directory all is fine. Problem with access only occurred after carrying out updates of Ubuntu 17.10 & LibreOffice (5.3 to 6) on the 24/2/18. Tried all the above solutions to no avail. Status of apparmor is -
sudo aa-status
[sudo] password for dave:
apparmor module is loaded.
12 profiles are loaded.
11 profiles are in enforce mode.
   /snap/core/4110/usr/lib/snapd/snap-confine
   /snap/core/4110/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
   /snap/core/4110/usr/lib/snapd/snap-confine//snap_update_ns
   snap.core.hook.configure
   snap.libreoffice.base
   snap.libreoffice.calc
   snap.libreoffice.draw
   snap.libreoffice.impress
   snap.libreoffice.libreoffice
   snap.libreoffice.math
   snap.libreoffice.writer
1 profiles are in complain mode.
   snap.simple-scan.simple-scan
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

Is a test directory being used for apparmor? As according to the /etc/apparmor.d/disable directory it should be disabled for office.

dave@dave-Aspire-V5-573G:/etc/apparmor.d/disable$ ls
temp usr.lib.libreoffice.program.soffice.bin
usr.bin.firefox usr.lib.libreoffice.program.xpdfimport
usr.lib.libreoffice.program.oosplash usr.sbin.rsyslogd
usr.lib.libreoffice.program.senddoc

Olivier Tilloy (osomon) wrote :

Please do not change the bug status. The fix is being tested and hasn't been released yet.

Changed in libreoffice (Ubuntu):
status: Fix Released → Fix Committed
The_Legacy (es-ei6hel-n1) wrote :

Hello everybody,
Thanks to informations given in #10 comment, I fully managed to get my LO work perfectly.

I can tell you this bug gave me hard headache because I wasn't able to open the documents I created myself and needed them to give my student their diplomas ...

Thanks a lots :-)

Hope this will be resolved in next updates. ;-)

holiday (stephenboston) wrote :

Very sorry. I was exploring the site and didn't understand the purpose of
the button. I was surprised to find that I had changed the status and was
even more surprised that having changed it I hadn't the authority to change
it back.

On Mon, Feb 26, 2018 at 10:54 PM, Olivier Tilloy <
<email address hidden>> wrote:

> Please do not change the bug status. The fix is being tested and hasn't
> been released yet.
>
> ** Changed in: libreoffice (Ubuntu)
> Status: Fix Released => Fix Committed
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1751005
>
> Title:
> libreoffice cannot open a document not within $HOME
>
> Status in libreoffice package in Ubuntu:
> Fix Committed
>
> Bug description:
> Starting with today's update to LibreOffice 5.4.5.1 40m0(Build:1),
> files not within the user $HOME directory cannot be opened. This has
> nothing to do with ownership or permissions - the target document is
> owned by the user with full permissions. Moving the file to ~/Desktop
> allows it to be opened normally.
>
> Error message in popup window:
> Access to /home2/mico/documents/personal/2018 lists.ods was denied.
>
> Error message when launched from terminal:
> $: localc "2018 lists.ods"
> javaldx: Could not find a Java Runtime Environment!
> Please ensure that a JVM and the package libreoffice-java-common is
> installed.
> If it is already installed then try removing
> ~/.libreoffice/3/user/config/javasettings_Linux_*.xml
> Warning: failed to read path from javaldx
>
> The file mentioned in the error message does not exist.
> I removed the corresponding file under ~/.libreoffice/4/ but that makes
> no difference.
>
> This but started in Ubuntu 18.04 (alpha) around Feb. 15, and with
> today's update (Feb. 22) it appeared in Ubuntu 17.10.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 17.10
> Package: libreoffice-core 1:5.4.5-0ubuntu0.17.10.1
> ProcVersionSignature: Ubuntu 4.13.0-36.40-generic 4.13.13
> Uname: Linux 4.13.0-36-generic x86_64
> ApportVersion: 2.20.7-0ubuntu3.7
> Architecture: amd64
> CurrentDesktop: ubuntu:GNOME
> Date: Thu Feb 22 09:35:49 2018
> InstallationDate: Installed on 2018-01-27 (25 days ago)
> InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64
> (20180105.1)
> SourcePackage: libreoffice
> UpgradeStatus: No upgrade log present (probably fresh install)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/libreoffice/+
> bug/1751005/+subscriptions
>

magowiz (magowiz) wrote :

just to add mine experience :
libreoffice v. 5.4.5-0ubuntu0.17.10.1 ubuntu 17.10

I cannot open files at all, even if they are in /home/${USER}/ , I copied an xlsm file to ~/ and I cannot open it, disabling apparmor profile did the trick.

Does the issue came out because I got an encrypted home partition (created using ubuntu installer)?
$ mount | grep home
/home/.ecryptfs/${USER}/.Private on /home/${USER} type ecryptfs
[...]

If so, all users that have a crypted home partition cannot open libreoffice documents at all.

Christian Boltz (cboltz) wrote :

It looks like the "xlsm" extension is not included in the profile (checked with upstream LibreOffice 6.0.1.1). [Unless someone fixes this quickly and says so, this is probably worth a separate bugreport.]

To find out if the encrypted partition is a problem, try to open a file with a more common extension, for example "ods" or "xls".

magowiz (magowiz) wrote :

Ok Christian I tried with an odt, I removed links /etc/apparmor.d/disable/usr.lib.libreoffice.program.* and I rebooted to be sure to restore apparmor in previous state.

With odt file I can open it while it is in my home directory, I cannot open it if it is elsewhere,
so in this case the issue was with xlsm extension.

Olivier Tilloy (osomon) wrote :

@magowiz: thanks for confirming! Can you please file a bug against the upstream project (https://bugs.documentfoundation.org/enter_bug.cgi) to track the issue with the xlsm extension?

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libreoffice - 1:5.4.5-0ubuntu0.17.10.4

---------------
libreoffice (1:5.4.5-0ubuntu0.17.10.4) artful; urgency=medium

  * debian/libreoffice-common.preinst.in: added to disable apparmor profiles on
    fresh installs and upgrades from 1:5.4.5-0ubuntu0.17.10.1 (LP: #1751005)
  * debian/patches/apparmor-senddoc-fixes.patch: updated to reflect upstream
    commit

 -- Olivier Tilloy <email address hidden> Mon, 26 Feb 2018 15:17:18 +0100

Changed in libreoffice (Ubuntu):
status: Fix Committed → Fix Released
André Colomb (acolomb) wrote :

I can confirm that the just released version 1:5.4.5-0ubuntu0.17.10.4 fixes the problem for me. No more issue opening files from within a /srv hierarchy.

Péter Prőhle (prohlep) wrote :

If the bug is that terrorists abruptly divert aircrafts into high buildings,
then the total disabling the whole air traffic IS NOT A BUGFIX, but it is a
TEMPORARY WORK AROUND only! The real bug fix is when you reopen the public
air traffic with a better safety configuration!

To disable the apparmor is a temporary work around only. Since the foreign
office documents are harmful, and hence it is a valuable gift, that the
apparmor is suitable to protect say the local backup subtrees.

It is in fact a conceptual bug to assume, that peope work in their home.

Professionals, who were not brought up in the "My Documents", "My Photos"
and "Downloads" world, do work elsewhere on regular base.

Since the home tree became polluted by self invited and regularly changing
system configuration data, typically not for tampering by the user.

Remember please the happy 80's years, when the home containd exclusively
only that kind of configuratkon files, which were edited only by the user
itself. And as such, these user configuration files also belonged to the
fruits of the users's onwn personal work.

But nowadays, the professional approach is NOT to work in the home tree.

((I personally use 4 additional physical drives: /work and its local backup
/zzzz, and /xtra and its local backup /ytra. Hence I wish to access by
LibreOffice the regular /work and occassionally /xtra, and I wish to protect
their local backups: /zzzz and /ytra .))

Hence I suggest NOT TO CONSIDER THIS BUG "Fix Released", since disabling of
the protection IS NOT A BUGFIX. The bug is still there!

There should be a user configurable list of user subtree roots.

And there should be a HUGE WARNING in the LibreOffice error message, that
where can the user find that configurable list of user subtree roots.

Google the net please, and recognise please, how wide spread this bug is,
and ho many discussions DO not recognies, that the problem is not directly
with the LibreOffice itself, but only with the Windows-style missleading
error message and bad access configuration.

This bug is suitable to deter or discourage the users from LibreOffice and
hence from Linux systems.

Olivier Tilloy (osomon) wrote :

Apparmor profiles were not enabled before the 1:5.4.5-0ubuntu0.17.10.1 SRU.
The SRU accidentally enabled them and broke a flurry of use cases. That was a very bad regression.
The 1:5.4.5-0ubuntu0.17.10.4 SRU disabled them again. Regression fixed, hence the status.

We will work towards enabling apparmor profiles in a controlled manner.

magowiz (magowiz) wrote :

@Olivier Tilloy (osomon): in response to #47 :

I don't understand, do you mean that the fact that apparmor blocks the opening of xlsm files (xls with https://fileinfo.com/extension/xlsm) by libreoffice is a libreoffice upstream bug?
This type of documents can be opened if the libreoffice apparmor rules are disabled.

There should be something I'm missing.....

Olivier Tilloy (osomon) wrote :

@magowiz: yes, the apparmor profiles are maintained as part of the upstream project (here: https://cgit.freedesktop.org/libreoffice/core/tree/sysui/desktop/apparmor/), so issues with them should be filed upstream.

magowiz (magowiz) wrote :

I see, so libreoffice staff generates their own apparmor profiles, thank you for the explanation.
Here it is the upstream bug report : https://bugs.documentfoundation.org/show_bug.cgi?id=116086
I hope I've been clear in explaining the issue.

Sam Van den Eynde (samvde) wrote :

So 2 questions still remain:

- if we executed the preliminary work around to disable the profiles, do we need to take action to revert those and go back to "stock" configuration?
- what about the snap version of LO? As I mentioned it does not honor "classic" confinement

Olivier Tilloy (osomon) wrote :

Thanks for the report @magowiz!

Olivier Tilloy (osomon) wrote :

> if we executed the preliminary work around to disable the profiles,
> do we need to take action to revert those and go back to "stock"
> configuration?

No, no further action is needed on your part, as the update does essentially the same as the workaround you applied.

> what about the snap version of LO?
> As I mentioned it does not honor "classic" confinement

No indeed, the libreoffice snap is strictly confined.
Accessing files outside of the home directory is a general problem that affects all strictly confined snaps. Would you mind starting a thread on https://forum.snapcraft.io/ to gather ideas on how we could address it?

Kasoroth (kasoroth) wrote :

I ran into a similar problem on Ubuntu 17.10 that I think is related to the apparmor profile, because it appeared recently, but has gone away with the newest release. I have an ODT file (in my home folder) that has no ".odt" at the end of the filename.

It has never had problems in the past (Nautilus recognizes the file type from the contents, and launches LibreOffice, which would open the file successfully), but suddenly it started giving me an access denied message, which went away if I added ".odt" to the name. Now with the newest release, it works again without the ".odt".

Confined apps seem like a good idea, but seeing the variety of different problems that this change has caused (and will probably cause in the future as more apps apply confinement) makes me a bit concerned about the overall confinement strategy in general, not just for LibreOffice.

It seems like trying to make a universal definition of what file names and locations are appropriate for an app to access is an impossible task. The problem is that in a broad conceptual sense, there are sort of three classes of files:
System Files: need to be protected from untrusted users and untrusted apps. OS determines names and directory structure
App Files: owning app needs has full automatic access, and chooses names and sub-directory structure.
User Files: user has full access, and chooses names and sub-directory structure.

It seems to me that a better approach would be to give each app one specific folder that it has completely free access to read and write "app-owned" files, like settings, saved games (maybe "~/.local/share/appname" or "~/Settings/Apps/appname"), and then have specific "Trusted File Pickers" (for example, Nautilus, or a system-provided Open/Save window) that could temporarily give the app permission to access a specific file selected by the user.

I don't know if apparmor is capable of doing this sort of thing, but it seems like a better general approach to app confinement. I don't want an untrusted application to freely read or write everything in my home folder, potentially stealing personal information, or deleting/encrypting my documents. I also don't want an app to be prevented from accessing a file that I explicitly try to open with it, just because of where it's stored, or how the filename is formatted.

The one downside I can see for a system like I proposed is that it would make it very hard for confined applications to provide their own custom Open/Save windows, but I think that would be a reasonable trade-off for having more security.

David Stewart (dlpastewart-5) wrote :

I have just updated Ubuntu 17.10 and LibreOffice 6.0.1.1 snap1, Rebooted my PC (even though it did not ask for it. Tested and still do not have access to my media/Acer files, access denied. Works fine in home directory. Also tried a libreoffice spread sheet file (with macros) in my home directory, and it worked fine.
Still having a deny of access to files not in home directory. David

Olivier Tilloy (osomon) wrote :

David, that bug was for the version of libreoffice in the ubuntu archive.

The snap is a different thing altogether. With it, you should be able to access your files under /media by issuing the following command in a terminal:

    snap connect libreoffice:removable-media

Files in other locations are not accessible, that remains a problem to be discussed and solved.

David Stewart (dlpastewart-5) wrote :

Thankyou Oliver that worked.

tags: added: regression-update
Dominik Hölzl (dhoelzl) wrote :

Hello!

I find it weird that accessing

* /home/<user>/.hidden/Document.odt DOES NOT WORK
* /home/<user>/Documents/.hidden/Document.odt WORKS
* /home/<user>/myfolder/.hidden/Document.odt WORKS

We have several applications which access documents under /home/<user>/.hidden which now does not work any more. Of course I could move all the documents to /home/<user>/Documents/.hidden, but this would require all applications to be adjusted for that.

Any suggestions?

Regards,
Dominik

Olivier Tilloy (osomon) wrote :

Dominik, can you confirm that this is when running libreoffice installed as a snap? (check the Build ID in the about dialog)

Dominik Hölzl (dhoelzl) wrote :

I have installed libreoffice manually as snap with the command "sudo snap install libreoffice".

Ubuntu 18.04

libreoffice build ID: libreoffice-6.0.4.2-snap1

Dominik Hölzl (dhoelzl) wrote :

One more issue:

Opening

* /home/<user>/.Hidden.odt DOES NOT WORK (access denied)

Opening

* /home/<user>/Document.odt DOES NOT WORK

 (LibreOffice complains that it can't create a lock file (which is a hidden file), and opens the document only read only)

Seems that accessing hidden files in the first level inside the home directory is denied.

Olivier Tilloy (osomon) wrote :

Ack. This is expected, the "home" interface for snaps doesn't allow reading/writing files to .dot directories directly under $HOME. This is to mitigate access to sensitive information. See https://docs.snapcraft.io/reference/interfaces.

Dominik Hölzl (dhoelzl) wrote :

Thank you!

So this behavior is freezed and I cannot expect a "fix" for this?

Opening documents directly in the home directory is intended to only work read-only?

We also have libreoffice extensions which require accessing files in the .hidden directory.
If I move them to the documents directory I have to find out the path of it e.g. via "xdg-user-dir DOCUMENTS", but will that work inside the libreoffice extension with limited access?
I could create a directory with a known name directly in the home directory and put all the files into it, but this could confuse users if there is a directory which contains only a hidden directory.

Olivier Tilloy (osomon) wrote :

Please continue this discussion on bug #1766192, this bug tracked a differente issue and is now closed (would you mind copying that last comment there?). Thanks.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers