https://bugs.documentfoundation.org/show_bug.cgi?id=98210
Bug ID: 98210
Summary: Pipe socket directory permissions checks incorrect
(R_OK not needed) and inconsistent
Product: LibreOffice
Version: Inherited From OOo
Hardware: All
OS: Linux (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: LibreOffice
Assignee: [email protected]
Reporter: [email protected]
Created attachment 123015
--> https://bugs.documentfoundation.org/attachment.cgi?id=123015&action=edit
Only require W_OK for socket dir, not R_OK, and bail with a useful error
Libreoffice silently fails at startup on UNIX if /tmp and /var/tmp are mode
1733 (i.e. not world-readable). The splash will paint, but then it exits, with
no error messages. Proposed patch attached.
It is a common system-hardening recommendation to make per-user TMPDIRs, and to
remove read permission from world-writeable directories. Generally programs
that create tempfiles know their names, and so do not need to readdir() the
temp directories.
In LibreOffice there are two implementations of pipe-path-selection; both
insist on R_OK in addition to W_OK, but they are otherwise divergent in
implementation and behavior. Neither catches errors and prints a diagnostic
error message.
If I understand the flow correctly, during startup one process calls
osl_psz_createPipe() from sal/osl/unx/pipe.cxx to create the OSL_PIPE_...
socket. Another process calls get_pipe_path() from desktop/unx/source/start.c
to attach to it.
These two implement things slightly differently. They both default to /tmp
followed by /var/tmp (PIPEDEFAULTPATH and PIPEALTERNATEPATH respectively).
They both ignore things like the TMPDIR environment variable. (Possibly this
is to avoid odd behavior if TMPDIR is on a shared filesystem, or one that does
not support socket files, etc. See for example
https://bz.apache.org/ooo/show_bug.cgi?id=55153 , this was deemed "not a bug"
in 2005... that is not the not-a-bug that I am talking about :).
However, from there on they diverge. desktop/unx/source/start.c contains:
if ( access( PIPEDEFAULTPATH, R_OK|W_OK ) == 0 )
rtl_uString_newFromAscii( &pResult, PIPEDEFAULTPATH );
else
rtl_uString_newFromAscii( &pResult, PIPEALTERNATEPATH );
...So, it checks if /tmp is both readable & writable, and if not, it selects
/var/tmp - but performs no checks at all on /var/tmp.
Meanwhile, sal/osl/unx/pipe.cxx contains:
if (access(PIPEDEFAULTPATH, R_OK|W_OK) == 0)
{
strncpy(name, PIPEDEFAULTPATH, sizeof(name));
}
else if (access(PIPEALTERNATEPATH, R_OK|W_OK) == 0)
{
strncpy(name, PIPEALTERNATEPATH, sizeof(name));
}
else if (!cpyBootstrapSocketPath (name, sizeof (name)))
{
return nullptr;
}
...It performs access() checks on both, falling back to cpyBootstrapSocketPath,
which uses OSL_SOCKET_PATH. It looks to me like this was added for iOS and
Android, and that such platforms use a different launcher than
desktop/unx/source/start.c. Since the latter was never updated to use
OSL_SOCKET_PATH as a fallback, it isn't usable there (if that was in fact
intended). The caller of the caller of the caller of get_pipe_path()
eventually gets the memo to give up, but no error is printed to the user,
libreoffice just exits.
The code has changed over the years, but as far back as the initial import in
2000-09-18, we see:
^9399c66 (Jens-Heiner Rechtien 2000-09-18 14:18:43 +0000 209) if
(access(PIPEDEFAULTPATH, O_RDWR) == 0)
So +r has been required for a very long time.
Anyway, I rebuilt LibreOffice with a patch I'll attach that:
a) removes the R_OK part of the access() checks in both start.c and pipe.cxx
b) adds to start.c the missing access() check for /var/tmp
c) adds an error-and-quit to start.c if the (now relaxed) access() checks still
fail.
This compiles and runs fine with /tmp and /var/tmp mode 1733, under some simple
light usage, but I have not tested extensively.
Notably, I did _not_ attempt to implement the OSL_SOCKET_PATH fallback in
start.c, because I'm not sure that's desired/intended, and it's more room for
me to get something wrong.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
