Closed Bug 105167 Opened 23 years ago Closed 23 years ago

Mozilla w/ NSS won't start w/ Readonly profile

Categories

(Core Graveyard :: Security: UI, enhancement, P3)

Product:
Core Graveyard
Component:
Security: UI
Version:
1.0 Branch
Type:
enhancement

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: timeless, Assigned: KaiE)

References

Details

Attachments

(2 obsolete files) 

Steps:
create a profile. make the entire profile readonly. build mozilla w/ crypto. run
mozilla.

worldgate's Expected results: Mozilla Runs.
Actual results (before patch): Mozilla does not finish loading.

Solution: tiny patch which allows readonly NSS databases.

hrm, i'll probably have to do contributor line. Ah well, since this is a locked
partition i'll leave that nonsense up to you guys.  The code provided in the
following patch is probably (c) WorldGate.  The code is of course covered by MPL1.1

My version of the patch has some debugging printfs, if nss doesn't want to
retain those, that's fine w/ us.

    
    

    
  
->kaie.
cc relyea.

Assignee: ssaux → kaie
Priority: -- → P3
Target Milestone: --- → Future

    
    

    
  
OK 1) why the change from:

 if (init != Success) {
 }

 to:

 if (init == Success) {
 } else 

Why not simply add the new if inside the existing if.

2) is it your intention for NSS to fail if it can't find a profile (not cert or
key db's exist? If so the existing code is fine (though the style should be
cleaned up to fit PSM coding style). If you wish NSS to succeed with no
databases, there is an additional option...

bob

    
    

    
  
*** Bug 105036 has been marked as a duplicate of this bug. ***

    
    

    
  
*shrug* i have no opinion about the case where there is no database, nor do i
have any idea what to do about that case.

As for the code form, i could do

if ((NSS_InitReadWrite(profileStr) != SECSuccess) &&
    (NSS_Init(profileStr) == SECSuccess) {
  #ifdef DEBUG
    printf("NSS Init failed both RW and RO for some reason NSS feels that such a
failure justifies killing the app, we're sorry.\n");
  #endif
  return NS_ERROR_ABORT;
}
   
if your coding style allows that; it doesn't matter to me.

if (a()!=success) { if b()!=success) { die }} is also ok although it isn't my
preference, and since this is your module and i can't actually make the change,
it's really up to you.

    
    

    
  
OpenVMS needs to be able to ship a CD with Mozilla pre-installed and runnable. 
At the moment I run into this bug (I get a pop saying "Could not initialize the 
browser's security component... Please check the directory has no read/write 
restrictions...".

Any idea when we're likely to see this one fixed?

    
    

    
  
Can you guys get some version of this in for 0.9.6? 
Keywords: mozilla0.9.6

    
    

    
  
Brendan, I think we have not tested how Mozilla/PSM will behave when NSS runs in
readonly mode.

If the application (or NSS) is unable to run read/write, at the very least the
application is likely to behave unexpected, at worst it will crash, as the PSM
code doesn't currently expect NSS to run read/only.

I'm not sure if we should risk this.

Would it help if we added a command line option to Mozilla for this special read
only mode, but never use it automatically?

Another option: The newest patch forbug 75947 fixes the "non starting" Mozilla
problem. It will run, but with security completely disabled, not even running
read-only.

In the end, it might be worth having both, but I suggest, not without having it
tested and reviewed PSM to behave correctly in read only mode.

    
    

    
  
timeless, for some reason I thought Brendan posted the question. So, please
replace "Brendan" with "timeless" in my previous comment :-)


    
    

    
  
BTW, the reason timeless made the patch and posted it is because we _are_ using
this functionality, and require it (there's no reasonable workaround to a
read-only profile for us).  I imagine other embedded users will have similar
issues, and it now sounds like the VMS people need it too.

We have a patch; it's posted here; we're using it.  Quite honestly the if there
are bugs introduced by readonly profile then people could hit them even if the
profile isn't readonly (that's not the only thing that can cause file
creates/writes to fail).  I don't think there are likely to be many places that
care about a readonly profile; mostly just certificate code, and I doubt it will
misbehave if the write can't be done.

    
    

    
  
timeless, Randell, colin, please tell me: Would a commandline option
--read-only-security-mode help you?

I still think we should not go automatically to this read only mode without
giving feedback to the user. Can we agree on feedback?

Stephane, what do you think?


    
    

    
  
A command-line option to disable the warning message seems like the right 
solution to me. I would suggest read-only-profile-mode as this could then be 
used to catch any other read-only restrictions.

    
    

    
  
Nss operates just fine in R/O mode with the exception that you cannot update
your database (makes sense). You can't add tokens (probably not an issue on
OpenVMS). You can't generate keys and certs (more of a worry). You can't change
(or set your security password), and if one isn't set, you can't encrypt your
passwords.

I would presume that the CDROM is part of installation and eventually the user
will be able to create a normal writable profile. If that's not the case, it's
possible from an NSS point of view to store the security profile elsewhere. One
thing to be careful of.... NSS will start faster if you have a valid
preconfigured profile.

The upshot: there's not reason that we shouldn't support a R/O mode for
security, but you do need some way to eventually update your security state or
you will loose those features in your browser.

bob

    
    

    
  
Most of the issues raised above aren't a concern to us. The only one I know we
are considering is the unrecognized certificate.  Our current plan is to have
new certificates get sent to something special so that administrators can elect
to add them to the database at a later time.  When we have a fix for that I or
someone else from wgate will file a bug and provide the npl/mpl required patch
portion.

There's no guarantee a user will ever take mozilla off a cdrom and run it w/ r/w
suppport.
Another interesting application is MacOS iTools iDisk distribution of
mozilla/netscape6, where someone might try to run mozilla directly from the
iTools iDisk, currently this doesn't work, people haven't tried to figure out
why, this might be among the reasons (although i doubt it).

An older instance which no longer strictly applies is BeOS install CDs.  BeOS is
a really cool os, what you would get in the box is a bootable CD that just boots
BeOS and lets you run the installer.  From experience, i've played video games
in BeOS while it was installing to a hard drive in the background. I would have
loved to go web browsing w/ mozilla while it was installing from the CD, and
creating an extra partition just for mozilla so i can surf while BeOS was
installing would really suck.  For now, replace BeOS w/ some other OS name, the
idea should apply there too [QNX is my current pet project, but it in one form
fits on a floppy, but w/ mozilla i'd use the CD version ;-)].

From my perspective i don't want to have to give mozilla a flag to do something
when i know it doesn't need to require a flag.  As the beos end user or a macos
end user i wouldn't really know how to give it a flag, and having a script to
run mozilla would look really ugly.  Most likely in either case the average end
user would launch the application instead of the wrapper script, get the
appcrashed error and never try to figure out how to make it work.

wrt robert's comments, wgate indeed has a preconfigured readonly profile, and we
will make additional preconfiguration changes as needed (such as adding
additional certs as mentioned earlier).

for reference, wgate did not build psm for a while because it caused the browser
to quit.  https and such are a requirement for our product, if we wanted to run
w/o PSM we wouldn't build it.

    
    

    
  
Is there some reason why we *want* a read-only profile dir? That pretty much
defeats its purpose. Many other things need to write to the profile dir. Maybe
the main concern here is NSS because it reacts more harshly than most
components. If we want the app to run off a CD or an iTools disk, fine. We
should be placing the profile where it *is* writable. If the profile dir needs
to be read-only, why have it?

    
    

    
  
Good point, if the whole profile is readonly, you can't even store your
passwords. or cookies or bookmarks or mail messages or .... I can see the use
(even the need) to have a R/O profile under certain conditions, for very
restricted environments, but if you never have the ability to modify the
profile, you will loose most of the interesting features of Netscape 6.

That being said, I agree we still need have a way to start PSM with a read only
profile (which is the point of this bug I believe), and it should be realitively
easy since the files in the profile are openned by NSS, which knows how to
operate in a read only mode (because most of the servers operate with NSS read
only --- only their admin console opens the profiles r/w).

bob

    
    

    
  
We make the profile RO for a few reasons.  One is that we don't want 10 zillion
files clogging up our FS or servers - our design has potentially hundreds of
thousands of users sharing the server, with 10's of thousands online
simultaneously (10-20 per diskless client machine).  The client machines don't
want to RW mount the server because the load for RW mounts is much higher (and
the amount of data we try to write on exit).

The number of inodes would be a problem, too.

Many parts of "Netscape" (Mozilla) are turned off (global history, prefs,
bookmarks, etc), though some may be used in the future (mail, password
history).  For things that _need_ persistant data (mostly cookies, in the future
email/passwords, etc) we read/write the data via HTTP GET/POST and let a
database store it on the server.


    
    

    
  
OK, then you just need to make sure you can post updates to your security files
as well. Security doesn't need to update that often, but it does need to update.
There's no problem running NSS R/O for most things as long as the user has ways
of updating his password, creating keys/certs, and to a lesser extent modifying
his trust. These are actions that happen reasonbly rarely (creating keys/certs
happen about once ever 6months to once ever 2 years depending on deployments --
password update depends on users paranoia and the corporate policies, but
typical max frequencies are on orders of months). If the site administrators
handle the trust, you probably don't need the users editting it (depending on
the sophistication of the users).

My point is you will need to allow these things to change in order to use the
security features on Mozilla (and don't underestimate what uses these security
features -- particularly with S/MIME going into the next release), but those
changes are time wise rare, and it makes perfect sense to start Mozilla with R/O
access to the security databases -- just be aware that you will need to provide
ways to up data these if you are ever to use these features.

One other point--- all of these databases are controlled by the internal PKCS
#11 module. It's quite possible to add your own PKCS #11 modules with simply
supply your own modules which will handle many of these functions through a
client/server method that doesn't require a file system.

bob

    
    

    
  
Another question:

What happens when you start the browser from r/o media?

Does the browser create a new profile on the local disk, or will it use a
profile that you ship on the media?

If you ship a prepared profile, could we create a new setting in prefs.js to
enable r/o mode?

And I'm curious, how do you control what profile directory the started browser
will use? My understanding is: The browser will always look for the profile on
the operating system dependent path. I didn't see a command line option for
specifying the profile directory.


    
    

    
  
we have a profile which already exists and which should be the only profile 
mozilla will find, so it skips the profile manager and walks straight to our 
pre configured profile (which the clients mount readonly).

our target audience is not sophisticated (if they were they wouldn't be using 
us). some admin type person would be responsible for updating the certificates 
as needed.

as for s/mime, we currently aren't concerned w/ mailnews, we don't build it and 
don't plan to ship it in the first incarnation. beyond that, we'll cross that 
bridge if/when we come to it.

putting a preference into prefs.js rubs me the wrong way for various reasons. 
one is that i expect mozilla to do the right thing. another is that i should be 
able to copy a preference file or profile to another system and continue using 
it.  This would include perhaps browsing in order to enhance the profile before 
resealing it for a new RO lifespan.  the fact that i can use user.js or 
something to get around this isn't good enough and would certainly cause 
problems when someone missed that file/step/setting.

    
    

    
  
So just a couple of comments:
1) what you are doing is quite reasonable, but it means you will have to take on
some extra burdens to make everything work out correctly. Hopefully the features
in the next release of PSM should be sufficient.
2) Don't underestimate what unsophisticated user will want/need to do. Setting
passwords and letting communicator keep track of their web login passwords is
something an unsophisticated user is more likely to do than a sophisticated one.
Knowing that you have this requirement can help us set up ways for you to
accomplish these without opening up the profile to r/w access.
3) As far as prefs are concerned, Correct behavior for Mozilla would be to warn
if it didn't get r/w access to it's databases under normal conditions. Systems
which quietly not work because something is wrong causes people to think that
the program just doesn't work rather than they have something misconfigured (For
the longest time I thought bookmarks were just broken in .96, not that my
bookmark file had grown too large) While what you are doing is reasonable, it's
not the common/normal operating conditions, so you should expect to have to have
different settings to prevent this warnings. If your point is that PSM should
come up (after the appropriate warnings) even if it couldn't open the databases,
you are quite correct. The prefs would just adjust whether your are warned or
not(and maybe reduce some startup time for read-only profiles as the back off
from trying to start r/w).

bob

    
    

    
  
A pref to turn off a warning doesn't seem unreasonable to me.

As for password memory issues; we can (and probably would) make those avoid
calling write() at all; we'd pass the data to a server via an HTTP post to be
stored in the user database (and read it via HTTP) - we do this for cookies
now.  (This is the same database that holds the user's main password, so this
isn't that much of an additional security risk, especially if we encrypt the
data somehow.  In any case, that's another (private) discussion.)  For the time
being we're disabling password memory until we can mung the password read/write.


    
    

    
  
I found another argument, why I would prefer the following behaviour:

- try to init NSS r/w
- if it fails, init NSS r/o
- look for a "disable NSS r/o warning" preference
- if warning is not suppressed, warn the user

The current patch in bug 75947 uses a neat trick to disable instantiating of any
PSM objects, if first init of NSS fails.

However, this trick will not work when the application decides to switch the
profile. PSM has no control over who was still references to PSM objects when
the profile is being switched.

For that reason, the "disable instantiating PSM objects" could only work for new
instances requested, but not for those already alive.

For that reason, unless we rewrite PSM to behave failsafe if NSS couldn't be
initialized at all, I want to vote for the automatic read only mode.

But I really think we should warn to the user, unless the profile suppresses it.

Unless we redesign PSM to detect the r/o mode and behave approriately, the user
will be confused. While this is no problem in thoses cases where you explicitly
have set up a r/o environment, it is problem in those environments where the
profile becomes accidentially r/o. This includes the "disk full" environment.


Status: NEW → ASSIGNED

    
    

    
  
Kai,
Your solution is reasonable. Please implement it.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Suggested fix (obsolete)
        — 
          — Splinter Review
      

    


  
The attached patch implements the automatic read-only mode, the user feedback,
and the preference that can be used to suppress a warning in the "read/write
not possible" environment.

While this bug should work, we shouldn't check it in now. I see that it depends
on bug 75947. Reason: All of our windows continue to depend on the entropy
collector. I implement the warning using a XUL window. As currently, the
entropy collector is within NSS, this will lead to a recursion when we need to
show an error message.

We can start getting reviews for this code, but we can't check it in until bug
75947 has been checked in.

        Attachment #53876 -
        Attachment is obsolete: true

    
    

    
  
See previous comment for why this needs to depend on bug 75947.

Depends on: 75947

    
    

    
  
Any objections against this patch?
If not, Javi, can you please review?


    
    

    
  
why can't you use nsIPrompt for alerting the user?  This would remove the 
dependency on xul and be embedding friendly as well.

    
    

    
  
Javi: I actually do use the nsIPrompt service, but that depends on XUL - or
whatever is not yet up and causes the recursion.


    
    

    
  
By the way, part of the fix for 75947 will be code that removes the hack from
bug 76915.


    
    

    
  
in mozilla, nsIPrompt depends on xul.  But in other environments this may be a 
native implementation.  If you're using nsIPrompt, that's preferable.

    
    

    
  
If profile has switched, and for some reason the new profile directory is r/o,
and there are no usable security database files in that directory (not even
r/o), I will add a call NSS_NoDB_Init().

I can't prevent PSM instances from being created if they were allowed to be
created during the first profile being used during application run. Therefore I
want to make sure that NSS is at least initialized, even if it will not work as
expected.


    
    

    
  
Comment on attachment 57849 [details] [diff] [review]
Suggested fix

This patch will land together with the patch in bug 75947.

        Attachment #57849 -
        Attachment is obsolete: true

    
    

    
  
Checked in, fixed.

The name of the new boolean preference is:
  security.suppress_nss_rw_impossible_warning

There is no UI for it, you have to set it manually.

This will only prevent a warning, when the browser finds valid certificate
database files, but falls back to read only mode.

In case even read only mode does not succeed, a warning will be shown regardless
of this preference, and browser will fall back to a mode without using any
security database files.


Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED

    
    

    
  
Verified fixed.
Status: RESOLVED → VERIFIED

    
  
Product: PSM → Core

    
  
Version: psm2.1 → 1.0 Branch
Product: Core → Core Graveyard

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: