2

Permission denied shows up when I try to open some attachment in Thunderbird. Yet, it doesn't look as a Thunderbird bug, because when I strace the process I see it issues the correct call. Yet it fails.

11545 execve("/usr/local/bin/libreoffice6.4", ["libreoffice6.4", "--writer", "file:///tmp/user/1000/via%20alla%20quite%2012%20Laigueglia"], ["SHELL=/bin/bash", "WINDOWID=18874383", "QT_ACCESSIBILITY=1", "XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0", "XTERM_VERSION=XTerm(344)", ... ]) = -1 EACCES (Permission denied)

Permissions are good, I tested with namei and getfacl. Then I copied the execve instruction from strace -v -s 1024 to a C file and compiled it. In that case, it succeeds. Every time I run it by mouse clicks in Thunderbird it fails, every time I run the following test program it succeeds.

#include <unistd.h>
#include <stdio.h>

int main()
{
    char *path="/usr/local/bin/libreoffice6.4";
    char *argv[] =
    {
        "libreoffice6.4",
        "--writer",
        "file:///tmp/user/1000/via%20alla%20quite%2012%20Laigueglia",
        NULL
    };
    char *envp[] =
    {
        "SHELL=/bin/bash",
        "WINDOWID=18874383",
        "QT_ACCESSIBILITY=1",
        "XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0",
        "XTERM_VERSION=XTerm(344)",
        // ...
        NULL
    };
    int rtc = execve(path, argv, envp);
    perror("execve failed");
    return rtc;
}

Note that Thunderbird can open a number of attachments correctly. Only LibreOffice and a custom shell program fail, thus far. Both are not part of the stock distribution — Devuan Beowulf — but this cannot explain the failure, can it?

There is no point reporting the bug to Thunderbird, because it is an old 68 version, and the bug may be fixed already or perhaps will disappear spontaneously on the next install. Certainly, I cannot report it if I have no clue of what the heck goes wrong. I don't understand how come the access is alternately denied and granted.

  • I run Thunderbird and the straw man program under the same userid/ session.
  • Thunderbird doesn't seem to call any of trace=setuid,setfsuid,setreuid.
  • The x bit is on on each part of the relevant paths.
  • I never used ACLs.

Edit: The man page for execve lists four possible reasons for EACCESS:

  • Search permission is denied on a component of the path prefix of filename or the name of a script interpreter.
  • The file or a script interpreter is not a regular file.
  • Execute permission is denied for the file or a script or ELF interpreter.
  • The filesystem is mounted noexec.

None of those appears to be true. I complicated the straw man program adding dummy thread_creations and forks to mimic Thunderbird behavior. In particular, running this executable:

-rwxr-xr-x 1 root root 14328 Nov  6  2019 /usr/lib/x86_64-linux-gnu/glib-2.0/gio-launch-desktop

Note that it is part of libglib2.0-0:amd64, not Thunderbird.

Still, I cannot reproduce the failure as experienced by Thunderbird.

Edit2: Submitted the case against libc6 to both Devuan bug 497 and Debian bug 966343

  • "intermittently" is a misleading word to use for every time that I do this it happens. – JdeBP Jul 24 at 17:49
  • @JdeBP The point is that doing the same thing the result differs as in hysteresis. Since hysterically means something different, I tried intermittently. Is there a better word? – Ale Jul 25 at 10:55
  • Not sure why this question scored a down vote. Besides the misuse of a single word it seems a good question. – Philip Couling Jul 27 at 8:54
  • Apparmor policies or similar restrictions in play? – muru Jul 27 at 9:15
1

This is a theory, not a conclusive answer...

There are other reasons for Permission Denied. The one that springs to mind is AppArmor. I've not checked to see if this affects Thunderbird on your distro. It should write to the syslog when blocking a program's access so check /var/log/syslog.

This would neatly explain your issue because AppArmor is configured per program and by default will let unknown programs do whatever they like. Thunderbird might have an AppArmor profile preventing it from executing other programs (OpenOffice). Your own test program would not have such a profile.

| improve this answer | |
  • Correct. Mark Hindley also pointed out this solution. This reason is not documented in execve man page. – Ale Jul 27 at 10:44
  • 1
    @Ale Yes I think it's not documented because it's provided by an extension (Kernal Module). It wouldn't be possible to document every extension on a single man page. That said, the man page could mention security extensions since they are prevelent. – Philip Couling Jul 27 at 10:52
  • I doubt all security modules result in similar failures. For example, returning EACCES whenever permission is denied, and not, say, EPERM. LSM hooks seem to leave too much rope to extensions, thereby impeding a precise general documentation. – Ale Jul 27 at 17:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.