228220 - Starting Moz deletes Cache directory for user account.

Status: RESOLVED EXPIRED

(SeaMonkey :: General, defect)

Description

[Terrence Branscombe]

User-Agent:       Mozilla/5.0 (X11; U; OpenVMS AlphaServer_1000A_4/266; en-US; rv:1.5b) Gecko/20030827
Build Identifier: Mozilla/5.0 (X11; U; OpenVMS AlphaServer_1000A_4/266; en-US; rv:1.5b) Gecko/20030827

According to the security audit, each time Mozilla is started the <user>$CDEnnnn
process attempts to delete the CACHE.DIR file from the
SYS$LOGIN:[_MOZILLA.DEFAULT.nnnnnnnn_SLT] directory.  However, the file
protections created by the Mozilla installation procedure do not allow its owner
to delete it, i.e.:

$ DIR/PROT SYS$LOGIN:[_MOZILLA.DEFAULT.nnnnnnnn_SLT]CACHE.DIR

CACHE.DIR;1          (RWE,RWE,RE,E)

The security audit appears like this:

=====================================================================

      Date / Time         Type        Subtype       Node    Username    ID    Term
-------------------------------------------------------------------------------
Security alarm (SECURITY) and security audit (SECURITY) on SZEGED, system id: 1
Auditable event:          Object access
Event information:        directory entry removal request (IO$_DELETE)
Event time:                9-DEC-2003 16:17:51.92
PID:                      00000A49
Process name:             <user>$CDE002
Username:                 <user>
Process owner:            [<user>]
Terminal name:            MBA5798
Image name: SZEGED$DKA0:[SYS0.SYSCOMMON.][MOZILLA]MOZILLA-BIN.;1
Object class name:        FILE
Object owner:             [<user>]
Object protection:        SYSTEM:RWE, OWNER:RWE, GROUP:RE, WORLD:E
Directory name: _SZEGED$DKA100:[<user>._MOZILLA.DEFAULT.nnnnnnnn_SLT]CACHE.DIR;1
Directory ID:             (204,5,0)
Directory entry:          CACHE.DIR;1
Access requested:         DELETE
Sequence key:             01105065
Status:                   %SYSTEM-F-NOPRIV, insufficient privilege or object
protection violation
--------------------------------

Anyone know why the default behaviour is to delete CACHE.DIR itself, rather than
its contents?  In fact, why would it delete anything each time Mozilla was
started?  If the directory was in fact deleted each time Mozilla started then
the cache itself would be pretty useless. Isn't the whole point of the cache to
keep rendering time down?

Just for kicks, I set default protections for the nnnnnnnn_SLT directory with:

$ SET DEFAULT SYS$LOGIN:[_MOZILLA.DEFAULT]
$ SET SECURITY/ACL=(DEFAULT_PROTECTION,S:RWED,O:RWED) nnnnnnnn_SLT.DIR

...then deleted the existing CACHE.DIR and restarted Mozilla.  This resulted in
the creation of a new CACHE.DIR, but Mozilla managed to reset file protections
for OWNER back to RWE instead of using the ACL value of RWED.

Anyone have any thoughts on any of this?  Are these legitimate questions, or am
I simply confused about something.  My money's on the latter, but I'm hoping for
the former. 


Reproducible: Always

Steps to Reproduce:



Expected Results:  
1. It's not clear to me why the default behaviour is for the user's CACHE.DIR
directory is deleted at each startup of Mozilla, unless this were made an
explicit Cache preference for some security reason.  Seems to me the cache
should, by default, only be cleared when the user clicks the "Clear Cache"
button in the Cache preferences.

2. If the cache _is_ cleared, it's not clear why Mozilla would try deleting the
user's CACHE.DIR file rather than the contents of that directory.


OpenVMS Alpha 7.3
DECwindows 1.2-6
TCPIP Services 5.4

Comment 1

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 2

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.