208909 - compreg.dat protection problem [OpenVMS status is decimal 114690]

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Colin Blake]

When Mozilla is first installed, the file compreg.dat (in components directory)
is correctly protected as W:RE. This is what is required for a non-privileged
user to be able to run Mozilla.

But after a privileged user has run Mozilla, the protection on compreg.dat is W
nothing. Then a non-priv'd user can't run Mozilla any more. The error message
given in this case is very misleading:

$ @sys$common:[mozilla]mozilla
Starting mozilla-bin...
LoadPlugin: failed to initialize shared library
/sys$common/mozilla/plugins/libnullplugin.so
[OpenVMS status is decimal 114690]
$

Comment 1

[Matthias Versen [:Matti]]

-> XPCOM

Comment 2

[Colin Blake]

Here's what's going on (this is a VMS problem, which is why I assigned the bug
to me in the first place; I don't know why it got re-assigned to Doug, but
that's OK, cos now I need Doug's input!).

On OpenVMS, each user can set the "default protection" which they want applied
to newly created files. The default "default protection" is equivalent to the
UNIX 0640, and its VERY rare for a user to change the "default protection" to
something which allows access to the world (such as 0644 or 0666).

By default, calls to the C routines open(), creat(), etc, will create the file
with the mode (protection) which was specified in the call. This caused grief to
OpenVMS users because Mozilla 0.9 (or whenever it was I started this stuff)
created files which were readable to the world, ignoring their specified default
protection, and they were unhappy. So I flipped a switch the C runtime which
basically says "ignore the mode on the creat() or open() call, and just user the
user's default protection". This made users happy, but is now the cause of my
current problem.

So that's the background. What I really need to do to fix this bug is to flip
the switch back in the C runtime so that files are created with the specified
mode (protection), AND make sure that only files which are REALLY meant to be
world accessible are created that way. Which brings me on to this question.

Why are the following files created 644:
open(.mozilla/default/8hu7c5iz_slt/XUL.mfasl, O_WRONLY|O_CREAT|O_TRUNC|0, 0644)

And why are the following created 666:
open(.mozilla/default/8hu7c5iz_slt/_parentlock,O_CREAT|O_NOSHR|0,0666)
open(.mozilla/default/8hu7c5iz_slt/_parentlock,O_CREAT|O_NOSHR|0,0666)
open(.mozilla/default/8hu7c5iz_slt/Cache/_CACHE_MAP_,O_RDWR|O_CREAT|0,0666)
open(.mozilla/default/8hu7c5iz_slt/Cache/_CACHE_001_,O_RDWR|O_CREAT|0,0666)
open(.mozilla/default/8hu7c5iz_slt/Cache/_CACHE_002_,O_RDWR|O_CREAT|0,0666)
open(.mozilla/default/8hu7c5iz_slt/Cache/_CACHE_003_,O_RDWR|O_CREAT|0,0666)
open(.mozilla/default/8hu7c5iz_slt/localstore.rdf,O_WRONLY|O_CREAT|O_TRUNC|O_EXCL|0,0666)
open(/m150opt/dist/bin/components/compreg.dat.tmp,O_WRONLY|O_CREAT|O_TRUNC|0,0666)

The only file which REALLY should be world accessible is compreg.dat, and that
should only be 0644, right?

Comment 3

[Doug Turner (:dougt)]

i think we are pretty inconsisent when determining what permisssions to use when
creating files.  

I am very sure that the cache files should not be using any world premissions --
those files are per user.

the xpcom files in /m150opt/dist/bin/components should have their permissions
set such that only root (or the accounts can install mozilla) has the ablity to
modify.

I am not sure about XUL.mfasl, but i would guess that this file is per user and
thus should not have world permissions set.

Comment 4

[Colin Blake]

For the files in the list, I think that all the ones which are in the user's
profile directory should be 0600 or 0640.

compreg.dat is in the installation tree and needs to be world readable so that
on a multi-user system anyone can run mozilla. It should NOT be world writable
as regular users may not have write access to the installation tree. So 0644
would be the correct protection.

Sounds right?

Comment 5

[Boris Zbarsky [:bzbarsky]]

I agree.  For files mozilla writes out to disk that are meant for use by other
programs we should use 0666 and let umask() kick in (if VMS has no umask,
perhaps we need to address that issue somehow).  For mozilla-private files, we
should use 0600 for profile-specific stuff and 0644 for global stuff...

Comment 6

[timeless]

Attachment: lock down and sanitize

Comment 7

[Doug Turner (:dougt)]

Comment on attachment 176882 [details] [diff] [review]
lock down and sanitize

i always hate file permissions.  Could you put a comment why each of these
values is selected so that in the future we will have a history as to why some
value was selected over the other.

Comment 8

[timeless]

Attachment: lock down and sanitize with comments

Comment 9

[Daniel Veditz [:dveditz]]

Comment on attachment 178204 [details] [diff] [review]
lock down and sanitize with comments

sr=dveditz

I bet what InstallPatch really ought to do is look at the mode of the original
file and preserve it.

Comment 10

[timeless]

Comment on attachment 178204 [details] [diff] [review]
lock down and sanitize with comments

mozilla/xpcom/components/nsComponentManager.cpp 	1.265
mozilla/xpinstall/src/nsInstallPatch.cpp	1.66
mozilla/netwerk/cache/src/nsDiskCacheBlockFile.cpp	1.8
mozilla/netwerk/cache/src/nsDiskCacheMap.cpp	1.19
mozilla/netwerk/cache/src/nsDiskCacheStreams.cpp	1.17