Issue 62858 - More secure permissions for the user directory by default
Summary: More secure permissions for the user directory by default
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOo 2.0.2
Hardware: All Linux, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2006-03-07 10:13 UTC by pmladek
Modified: 2017-05-20 10:55 UTC (History)
3 users (show)

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

One possible fix for UNIX. (672 bytes, patch)
2006-03-07 10:14 UTC, pmladek
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description pmladek 2006-03-07 10:13:05 UTC
OOo creates the directory with user configuration with the access rights 0755 by
default. It means that the user configuration is readable by anybody. I am not
sure if the temporary versions of documents are stored in this directory as
well. It would be a security hole, in  fact.

Anyway, from the security point of view, it would be better to create the user
directory with permissions 0700 by default.

I attach a patch that does it and works for me on Linux.

Note 1: It won't help to improve the method Directory::create to accept the
attribute parameter. It is because the aUserPath direcory is already created at
this point. It is created earlier when OOo writes something below

Note 2: I did the fix UNIX-specific because OOo does not provide the method
setAttributes for the object Directory. I was not sure if File::setAttributes
works on non-UNIX systems.
Comment 1 pmladek 2006-03-07 10:14:20 UTC
Created attachment 34625 [details]
One possible fix for UNIX.
Comment 2 Olaf Felka 2006-03-07 10:40:49 UTC
@ lo: Please have a look.
But if the $HOME is readable by anybody it's not a great security enhancement to
change only the user configuration of OOo :-).
Comment 3 Joost Andrae 2006-03-07 17:24:17 UTC
JA: I'm not really convinced to have hardcoded access rights here. The user
directory creation might better depend on the umask given by the underlying
operating system. To be discussed... Lars, what is your opinion about that ?
Comment 4 lo 2006-03-07 17:42:19 UTC
The umask applies to the creation of the user dir.
Temp files are already created in 'secure' mode.
I don't see a problem here, unless the above is not true.
Comment 5 pmladek 2006-03-07 17:49:07 UTC
More applications create this kind of directory with more secure permissions by
default. I see on my system, for example:

drwx------ 4 pmladek users 4096 2005-08-08 19:45 .ddd
drwx------ 6 pmladek users 4096 2003-03-29 22:02 .galeon
drwx------ 9 pmladek users 4096 2003-10-20 10:36 .gnome
drwx------ 5 pmladek users 4096 2006-01-23 16:00 .kde
drwx------ 5 pmladek users 4096 2005-09-08 09:47 .licq
drwx------ 2 pmladek users 4096 2004-03-02 20:33 .links
drwx------ 6 pmladek users 4096 2003-08-08 20:46 .netscape

I think that it depends on what kind of data are stored in the directory. I
think that the OOo user conf directory includes some personal data and should be
 better protected.

Another problem is that this directory is hidden, so the normal user often do
not know that it exists at all. Then he does not know that it is readable, ...
Comment 6 Joost Andrae 2006-03-08 10:31:41 UTC
JA->Matthias: I'd like to know you opinion regarding this request. Added you to
CC list
Comment 7 matthias.huetsch 2006-03-08 12:45:10 UTC
Hi pmladek, Joost,

Actually, I do agree with pmladek that we should always apply a "secure by
default" strategy.

While it is true that the users 'umask' is indeed applied (by 'mkdir(2)', see
'man -S 2 mkdir' on Linux), this is not "secure by default".

Regardless of the users 'umask', the OOo 'user directory' is a *user* specific
directory (where user private data may be stored), so that the creator of that
directory should indeed specify  mode  700 (instead of 777, and relying on an
appropriate umask).

While the proposed patch would indeed work (and I agree that it is apparently
the only quick change), I don't like it as it is. The proposed patch has an
inherent race condition: a 'chmod()' done some time after 'mkdir()' would leave
time for possibly bad things to happen.

As 'mkdir(path, mode)' already provides the right API to do the right thing, the
osl_createDirectory() (resp. osl::Directory::create()) API should probably be
extended to allow for the secure creation of the user directory (tree).

Again, it is less important how probable an exploit would be, than to be "secure
by default".

Comment 8 lo 2006-03-08 13:22:18 UTC
I aggree, that under a secure-by-default premise the directory should be created
700. I also aggree, that introducing the proposed fixed would violate said
premise and is thus not the apropriate solution.

The user-directory is currently being created when the configmgr is first
bootstrapped. It's kind of a side-effect when seen from the perspective of the
main application. The main application would create it, if it wasn't already
there, but in the current implementation it will always be there before the
userinstall code is reached.

If the osl::File API is extended as Matthias (mhu) proposes one of two thing
needs to happen:
a) the configmgr implementation must use the extended interface and creeate the
user-dir according to the secure-by-default premise, or
b) the creation of the user directory must be the responsibility of the main
application and the configmgr must no longer be allowed to create it's own
user-layer if the base directory isn't available.

I would prefere alternative (b), since it does away with an intransparent
Comment 9 pmladek 2006-03-15 19:46:41 UTC
Could you please clarify the preferred solution and point me to the related code?
I could help with implementaion then.
Comment 10 lo 2007-03-06 17:13:52 UTC
dispatch to framework
Comment 11 carsten.driesner 2007-03-08 13:18:27 UTC
cd->hro: It looks like your action is required first to fix this issue. Could
you please have a look. May be you can contact pmladek and give him information
which code must be extended.
Comment 12 Mathias_Bauer 2008-05-19 10:36:15 UTC
Unfortunately we forgot to change the owner...
Better late than never!
Comment 13 hennes.rohling 2008-05-30 11:25:55 UTC
Comment 14 kai.sommerfeld 2009-07-13 13:53:15 UTC
mav: Can you please take a look. Seems, that some osl file API change is needed
to solve the problem.
Comment 15 comtelicon 2010-11-11 01:05:13 UTC
Created attachment 73966
Comment 16 Marcus 2017-05-20 10:55:42 UTC
Reset assigne to the default "".