Closed Bug 70931 Opened 24 years ago Closed 11 years ago

Override salted Profile directory

Categories

(Core Graveyard :: Profile: BackEnd, enhancement)

Product:
Core Graveyard
Component:
Profile: BackEnd
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME
Milestone:
mozilla1.4beta

People

(Reporter: sds, Assigned: ccarlen)

References

Details

(Whiteboard: UBS (Union Bank Of Swiss))

Attachments

(1 file, 4 obsolete files)

fresher patch
22.92 KB, patch
Details | Diff | Splinter Review 
when I create a profile with 'mozilla -profilemanager', I specify the profile
directory which is then padded with "<profile-name>/junk.slt".
There should be a way to override this very annoying behavior.
If I specify a directory, this is what I mean, and nothing should be appended to it!
See bug 56002.  This is in place as a security feature to prevent a whole class
of attacks that involve reading the profile and/or writing things into the
profile (which is in a known location).

Over to profile manager:backend to decide whether we should provide a way to
override this behavior.
Component: Preferences → Profile Manager BackEnd
over to default owners
Assignee: matt → ccarlen
QA Contact: sairuh → gbush
Changing to RFE even though i think this is a really bad idea (from a security
standpoint that is).
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows NT → All
Hardware: PC → All
Summary: salted profile dir won't go away! → [RFE] Override salted Profile directory
This is an intentional security feature. It's unlikely that it will be removed.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
Target Milestone: --- → Future
verify
Status: RESOLVED → VERIFIED
Bah. Intentional it might be, but (on Mac OS at least) it's mildly offensive -- 
any file or folder (especially one inside the `Documents' folder!) should have 
a name which humans can understand.
Conrad, who has asked to "remove" that feature? As far as I understand, the
request was to have an option to "override" this feature if the user does not
want it. Wouldn't helpwanted/future/nobody@mozilla.org be more appropriate than
a WONTFIX?
Bug 56002 is rather long, but when I read it some time ago I thought the
behaviour is to reuse already existing non-salted profiles. If this is true, do
you suggest that people who don't want a salted profile directory use an
external utility program to create a profile in a non-salted directory that is
then detected and reused by mozilla? Isn't an option to the profilemanager the
simpler solution?
Is there any currently known way to share profiles?  I have a profile on my work
machine in ~/.mozilla/akkana (made before salts existed) and I'd like to copy it
to my home machine, but every time I try I find that it ignores the old profile
and creates a new one with a salt (and I can't copy files between the two
because the full pathnames don't match).  I don't mind doing some hand editing,
I just haven't managed to figure out what to edit to get it to accept the
saltless profile dir.

If someone can tell me how to make this happen, I'll be happy to document it on
mozilla.org somewhere (the customizing document?  Is there a better place?)  I'm
sure there are others who would like to know how to share profiles.
Akkana, this will all work when relative path names are used for profiles and
the profile mgr will prompt you to find a missing profile dir. That bug isn't
0.9 so, in the meanwhile, try this. Edit the file ~/.mozilla/appreg. This
contains the path to the profile dir for each profile. Chop out the salted part
from that path (or add the salted part from the other registry if you want).
Then moz will find your proifle dir. If it finds the dir, it won't create a new
one which will be salted. Then, there are various paths in prefs.js - those to
your mail folder, etc. Edit those as well.
Let's reconsider this (please dupe or add dependencies if appropriate). The
purpose of the salt directory is to make the path to the user profile directory
unguessable by an attacker. If the user specifies a nonstandard location for the
profile in the Create Profile dialog, this satisfies the unpredicatability
requirement, and salting is superfluous. So in deference to the users who find
the salting annoying, let's not salt when using a nonstandard profile location.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Target Milestone: Future → ---
Put that way - easy enough. I'll do it for 0.9.5
Target Milestone: --- → mozilla0.9.5
Additionally, please consider making the paths in the prefs files relative. 
This would allow someone to move the prefs dir around on a system or between
systems without breaking everything.
Relative paths are in Bug 12911
-> 0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Attached patch patch (obsolete) — — Splinter Review 

    
    

    
  
Sorry this sat here so long - it only took a few minutes to fix one I got around
to it. The patch makes it so that, if the profile dir to be created is outside
of the default location, it is not salted. Note that if you explicitly picked
the default location, it is still salted. I think this is right (safe). Do
people agree? If so, review it.
Status: REOPENED → ASSIGNED

    
    

    
  
Comment on attachment 55254 [details] [diff] [review]
patch

Looks good to me. r=mstoltz.

        Attachment #55254 -
        Flags: review+

    
    

    
  
the "recur" flag only works on Mac, on other platforms Contains will return true
for any path that starts with the default Path no matter how many levels are added.

At one point I thought the discussion turned toward only salting if the leaf
directory name was "default", not if it was in the standard parent directory? I
don't think the patch fulfills the thrust of this RFE since 1) it's not at all
obvious that people have to go to a different directory root to avoid the salt,
and 2) the fact of whether a salt is going to be added or not is completely
invisible.  A few folks may be aware of this fix, but basically the majority of
folks will be in exactly the same situation as now.

I like the suggestion from bug 97180 that the salted part be added to the
first-level directory name rather than creating an extra empty level. Saves an
empty directory, makes the salting obvious on the screen people see, and then
people could remove it at their own risk. Most won't, but for those who do it'll
be a lot clearer what's going on and what to do.


    
    

    
  
> the "recur" flag only works on Mac

I hope there's a bug on that somewhere. It shouldn't make much difference here
though.

> At one point I thought the discussion turned toward only salting if the
> leaf directory name was "default"

Good point. Mitchell - would that make it unguessable enough?

I think showing the salted name in the profile mgr UI and giving the user the
ability to remove it would confuse more people than it would help. If the way to
work around it is documented, I think it would be sufficient.

    
    

    
  
I'm fine with only salting the name if the name is "default." I think we should
get rid of the extra directory completely. When someone creates a "default"
profile, change the name to something unpredicatable. Don't add an option to the
UI regarding salting, it should be a feature that's completely transparent to users.

    
    

    
  
Mass move to 0.9.7
Target Milestone: mozilla0.9.6 → mozilla0.9.7

    
    

    
  
Heeeey - did someone check this in?  Mozilla lost my non-standard profile
(nightly 2001112508).  So I recreated it.  And guess what?  No salt.  :)

    
    

    
  
I just tried this with 2001112508 (Windows 2000), and it still salts for me.

Something else I noticed - I'm not sure if it's covered under this bug or not. 
The profile creator insists on appending the username to the directory path.  So
if I manually choose "c:\path"  it will make the directory "c:\path\username". 
Will this behaviour remain even after the salting is overridden and, if so,
should I open a separate bug for it?  (I don't remember it doing this in the
past, but it's been so long since I've created a new profile, rather than
recycling my old 4.x non-salted profile directories, that I can't comment on any
kind of recent behaviour.)

    
    

    
  
> The profile creator insists on appending the username to the directory path.

That's right. For every profile created, a directory to hold its contents
(username\) needs to be created. It has always done that and it's not a bug.

    
    

    
  
Right.  I'm off to create a new bug report then.  Half of my objection to
salting was that it took my manually provided path (saying *exactly* where I
wanted my profile data stored) and appended something I didn't want to it.  What
if I want my  data put in "c:\My Documents and Settings\JasonB\Mozilla"? 
Salting aside, I take it there is NO way of making Mozilla honour the above request?

    
    

    
  
Yahoo, no more salt!  [goes to generate a new profile and copy it to every machine]

I haven't seen the new UI for specifying the path (having trouble installing
today's build, the installer bombs out and has to be manually assisted), but if
we're always going to create a new directory named after the profile, I hope the
UI makes this clear, e.g. "Directory in which to create a new directory called
[profilename]" rather than "Path to new profile directory".  Otherwise I know
most of us are going to forget and be forever creating profiles with pathnames
like .mozilla/akkana/akkana.  Alternately, could it just use the last component
of the pathname as the profile name?  (I suppose that makes for difficult UI
since the profile name would then be shown in two places and would have to be
kept in sync.)

    
    

    
  
I've already opened up two bug reports on this <profilename> behaviour (bug
111940 and bug 112023). One was immediately marked as WONTFIX, the other is, no
doubt, on the verge of receiving the same treatment.

I was ecstatic to here that we were at the end of this salting saga - only to
discover that the profile manager insisted on adding <profilename> as a
subdirectory - again completely ignoring the explicit path entered by the user.
 Either it should not do this, or the UI for the profile manager should inform
users that this is going to happen (whether they like it or not).

    
    

    
  
-> 0.9.8
Target Milestone: mozilla0.9.7 → mozilla0.9.8

    
    

    
  
Help!  It's salting again.  I just tried on a machine with no .mozilla at all.
First it pretends that my old .netscape is a profile called "akkana"; if I let
it convert, then I end up with .mozilla/akkana/[salt].  If I delete the
non-profile from NS4 first, and create a new profile, the profile manager shows
me the directory .mozilla/akkana (there's a Choose button but I didn't press it
since that was the directory I wanted) but when I create the profile, again it's
created under .mozilla/akkana/[salt].

Did the no-salting fix get regressed?  Or is there a trick I'm missing?  And is
it considered a problem that we aren't honest with the user about the directory
where the profile will go (by not showing the salt)?

    
    

    
  
> Help!  It's salting again.

That's because this was never fixed. There were some reports of no salt, but I
don't believe them. The code hasn't changed. It will soon.



    
    

    
  

      
      
      
      

        Attached patch
          
          
        new patch (obsolete)
        — 
          — Splinter Review
      

    


  
This patch:
(1) Appends salt rather than creating a salted subdir
(2) Only salts if the name is the default name

Some more work was done to make the "default" name be consistent. Before, there
was a hardcoded string which was used to create a default profile without any
UI - as when launching the app for the first time with no old profiles to
migrate. Then, there was a 2nd localizable string, "Default User", used in the
UI. Now both cases use the same string from a bundle. I decided to use "Default
User" for both. I can't decide if "default" is better than "Default User" in
case anybody has an opinion on that ;-)

        Attachment #55254 -
        Attachment is obsolete: true

    
    

    
  
Can I get some r/sr of the last patch? It would be nice to have this behind us
in 0.9.8.

    
    

    
  
In progress, but not gonna make 0.9.8. -> 0.9.9
Target Milestone: mozilla0.9.8 → mozilla0.9.9

    
    

    
  
Again, can I get some review of the newer patch? Since this is an RFE, it may
have to be futured soon if I don't land it.

    
    

    
  
Comment on attachment 63276 [details] [diff] [review]
new patch

Should the "Default User" string be localized? What if someone runs two
different localizations of the product on the same machine, and tries to make
or share profiles? Other than that, sr=sfraser

        Attachment #63276 -
        Flags: superreview+

    
    

    
  
I also didn't like "Default User", because of directories with spaces being
unix-unfriendly and tending to break scripts.  And Simon's proably right that
localizing it is better.  Otherwise, I don't see any obvious problems with the
code; will test it tomorrow.

    
    

    
  
I have a new patch which again uses "default" when a default profile is made
from the back-end. The string in the UI is still the localized string from the
chrome ("Default User" in en-US) This localized string has to be checked for as
well as "default" when deciding whether to salt or not. Problem is, and
embedding app might not have this bundle, or the default name it uses in its own
UI might be something different, so comparing to the string from our bundle
would be useless.      
There's a way around this - not have a default name in the UI. That is, the
field comes up blank and the user needs to type in something in order to
proceed. If that's not objectionable, I'd like to do that.

    
    

    
  
At UBS, their deployment engine processes some scripts during the installation.
Thus, they need to fully precreate a profile path to access any contents of the
profiles at any time. Salted dirs make such processes more difficult.
 
Appends salt rather than creating a salted subdir ----
Does this term mean that 'salt' is appended to a profile-path which was created 
  using the profile manager?

Thanks
Niranjani

Whiteboard: UBS (Union Bank Of Swiss)

    
    

    
  
> Does this term mean that 'salt' is appended to a profile-path which was created 
  using the profile manager?

The patches here aim to salt only the default profile name. Others, made by the
user, won't be salted.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        another patch (obsolete)
        — 
          — Splinter Review
      

    


  
This patch gets around the problem I mentioned on comment #37 about checking
against a string from a localizable bundle. In the wizard, the profile name now
starts out blank, but focused and ready to type into - much more convenient. A
blank name is checked for as well as other possible problems with the name on
the wizard page validation function, rather than at the end of the wizard.

Need reviews.

        Attachment #63276 -
        Attachment is obsolete: true

    
    

    
  
CC'ing Marlon for his opinion on not having a default profile name in the wizard.

    
    

    
  
Is it not possible to simply display the text "default" somewhere in the UI but
not use it as input?  That way the user will know what they are getting if they
leave the input blank.

    
    

    
  
Since they can't leave it blank, there's no question as to what they're getting.

    
    

    
  
> The patches here aim to salt only the default profile name. Others, made by the
> user, won't be salted.

I don't understand.  If it can't be blank - just what exactly is the "default
profile name"?  In the past the default was used if no change was made.  If your
propose UI now comes up blank, but will not allow you to continue unless you
change it from blank, how is there a default?  (Unless you think that somebody
might actually type in "default" as their profile name?)

Or are you simply saying that you changed your mind about how to approach things
between post #39 and #40?  (My apologies if this is SPAM but it's not entirely
clear what approach is being taken here.)

    
    

    
  
Jason, there are two sources of the default name:
(1) the back-end uses "default" from a hardcoded string when there are no
profiles and none to migrate. It creates that profile without showing the UI.
(2) currently, the profile wizard uses "Default User."
With the patch, (1) will be salted and in (2), there will be no default. Unless
they enter "default" it won't be salted.

    
    

    
  
With today's linux build, if I move aside .mozilla and then run, I first get 41
repetitions of this assert:
###!!! ASSERTION: nsDependentString must wrap a non-NULL buffer: 'aPtr', file
../../dist/include/string/nsDependentString.h, line 54
Then I get the dialog about converting an NS4 profile.  (I have never
successfully managed to persuade mozilla to ignore my NS4 profile.  Is there a
secret to that?)

If I say yes, then I get 4 repetitions of:
### nsCacheProfilePrefObserver::Observe [topic=nsPref:changed data=browser.cache
.disk.enable]
followed by 
###!!! ASSERTION: the path does not exist.  see bug #55444: 'exists', file nsPre
fMigration.cpp, line 2000
and two repetitions of
###!!! ASSERTION: failed to copy pop file: 'NS_SUCCEEDED(rv)', file nsPrefMigrat
ion.cpp, line 1840
then five repetitions of
### nsCacheProfilePrefObserver::Observe [topic=nsPref:changed data=browser.cache
.disk.enable]
then
pldhash: for the table at address 0x0x81d0504, the given entrySize of 28 probabl
y favors chaining over double hashing.
pldhash: for the table at address 0x0x8328a94, the given entrySize of 28 probabl
y favors chaining over double hashing.
###!!! ASSERTION: nsDependentString must wrap a non-NULL buffer: 'aPtr', file ..
/../dist/include/string/nsDependentString.h, line 54
###!!! Break: at file ../../dist/include/string/nsDependentString.h, line 54
###!!! ASSERTION: nsDependentString must wrap a non-NULL buffer: 'aPtr', file ..
/../dist/include/string/nsDependentString.h, line 54
###!!! Break: at file ../../dist/include/string/nsDependentString.h, line 54
WARNING: 

and then it hangs and I have to kill it.

If I remove the .mozilla it created and try again, this time saying "manage
profiles" instead of letting it convert, I get a crash before the profile dialog
comes up:

#0  0x40966856 in nsWebShellWindow::LoadContentAreas (this=0x81861d8)
    at nsWebShellWindow.cpp:1454
#1  0x40965910 in nsWebShellWindow::OnStateChange (this=0x81861d8, 
    aProgress=0x82384cc, aRequest=0x8284440, aStateFlags=786448, aStatus=0)
    at nsWebShellWindow.cpp:1281
#2  0x4121c65f in nsDocLoaderImpl::FireOnStateChange (this=0x82384b8, 
    aProgress=0x82384cc, aRequest=0x8284440, aStateFlags=786448, aStatus=0)
    at nsDocLoader.cpp:1109
#3  0x4121b770 in nsDocLoaderImpl::doStopDocumentLoad (this=0x82384b8, 
    request=0x8284440, aStatus=0) at nsDocLoader.cpp:749
#4  0x4121b47a in nsDocLoaderImpl::DocLoaderIsEmpty (this=0x82384b8)
    at nsDocLoader.cpp:645
#5  0x4121b1e9 in nsDocLoaderImpl::OnStopRequest (this=0x82384b8, 
    aRequest=0x8315698, aCtxt=0x0, aStatus=0) at nsDocLoader.cpp:575
#6  0x40b9b275 in nsLoadGroup::RemoveRequest (this=0x81c94c0, 
    request=0x8315698, ctxt=0x0, aStatus=0) at nsLoadGroup.cpp:526
#7  0x40c0329d in nsJARChannel::OnStopRequest (this=0x8315698, 
    jarExtractionTransport=0x82e2c9c, context=0x0, aStatus=0)
    at nsJARChannel.cpp:615
#8  0x40c221a8 in nsOnStopRequestEvent::HandleEvent (this=0x82e37a0)
    at nsRequestObserverProxy.cpp:212

(further stack trace or variable info on request.)

    
    

    
  
It turns out these are all unrelated problems.  They happen without the patch,
too.   So the problems block testing of the patch but aren't caused by it.

    
    

    
  
The DependentString asserts should now be fixed.  The other problem sounds like
today's Linux smoketest blocker...

    
    

    
  
With various fixes for today's blockers, the patch works in the limited testing
I've done on linux.

newProfile1_2.properties and newProfile1_2.dtd don't end with newlines --
doesn't that cause problems?  

The rest of the code looks fine, r=akkana.

On the issue of whether to put a default in the dialog.  I think it's a little
confusing to have it blank, and would lean toward prefilling it and selecting
the contents (so that the user can start typing without having to click or
select anything), but Conrad pointed out that people won't see this dialog
unless they explicitly ask for it, and anyone who asks probably intends to
choose a name ... and I can't argue with that logic.  I"ll defer to Marlon (or
whoever feels strongly about it), and that's an easy thing to change after the
fact so the code probably shouldn't wait on a definitive answer.

I also raised a question: with the old code, if I don't automigrate and instead
"manage profiles", delete the name for the profile it wants to automigrate then
create a new profile, I find that every time I install a new nightly it prompts
me to automigrate again, ignoring the existing profile (but only on the first
run, after which it's content to use the existing profile).  I was hoping that
the fix for this bug would also fix that problem (not everyone wants to
automigrate, especially if there's a big batch of mail in the NS4 profile) but I
can't test that without a new nightly.  If it still happens, it's a separate bug
(but relevant for the folks who have said they want to make a master profile to
distribute to their users, since some of those users might have NS4 profiles).

    
    

    
  
Simon, can you sr= the latest patch? The gist of it vs. the last is in comment #40.

    
  
Target Milestone: mozilla0.9.9 → mozilla1.0.1

    
    

    
  
Is there an FAQ or can someone tell me how to un-salt a directory manuly?

    
    

    
  
I'd give a lot to know that information myself.  I don't, however, think it's
possible.  At least nobody could tell me how to do this many months ago when I
asked a simiilar question.  It has something to do with the "registry.dat" file.
 I've tried editing the text string in there, to change it from its salted
position to another one I created, but that didn't work.

    
    

    
  
Wouldn't it be better to let the user decide wether he wants to salt a directory
or not. I Think a checkbox in the front-end named "salt directory (more secure)"
or "obfuscate directory..." that is checked by default would be appropriate.

    
    

    
  
manual un-salting:
1. rename your 123456.slt to mydir.slt
2. replace 123456.slt with mydir.slt in "~/.mozilla/appreg"

    
    

    
  
"~/.mozilla/appreg" does not exist on Windows systems.  (I don't know about
Macs.)  I suspect that this is Linux/Unix only.

    
    

    
  
for windows it's something like Application Data\Mozilla\registry.dat

please read the latest release notes, they indicate where the file lives and 
what its name is.

    
    

    
  
Yes, registry.dat under Windows is the file that controls the location of the
profile directory, but it cannot be hand-edited.  I have tried to do so and it
had no effect.  Apparently only by changing the C++ source code that controls
the creation of this file can you modify the profile directory location that it
points to.  (Which is not practically possible for most people.)

    
    

    
  
Is this ever going to be implemented? It looks like the patch has been done and
awaiting verification for over eight months. Are the higher ups concerned that
if this was implemented most people would remove salting from their profile, and
end up solving 99% of the salting related issues so no one will spend the time
trying to fix them?

    
    

    
  
Comment on attachment 67900 [details] [diff] [review]
another patch

um, afaict this patch changes the semantics of a frozen interface and is
therefore unacceptable.

    
    

    
  
> um, afaict this patch changes the semantics of a frozen interface and is
therefore unacceptable.

Wrong. There are no changes to idl ifaces in the patch, much less frozen ones.



    
    

    
  
ccarlen, while that is true, this patch does change how the useExistingProfiles
parameter behaves, doesn't it?



    
    

    
  
Not to get impatient, but is this “bug/feature” done? If so I would like the
Assignee ccarlen@netscape.com (Conrad Carlen) to nominate it for 1.2beta branch
that has just opened up. With 10 votes, that more them most of the other
submited paches 

http://bugzilla.mozilla.org/show_bug.cgi?id=1.2b

    
    

    
  
there is no 1.2 beta branch and will not be. 1.2b will be released from trunk,
as were 1.1a and 1.1b and 1.2a...


    
  
Summary: [RFE] Override salted Profile directory → Override salted Profile directory

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Less bitrotted patch (obsolete)
        — 
          — Splinter Review
      

    


  
The patch was way bitrotted.  Since I also would like to see this checked in
(salted profiles make my own profile management more complicated, plus I'm
tired of having people outside mozilla complain to me about how they don't use
mazilla because they can't prepare profiles for their users) I have attempted
to bring it up to date.  String and file classes have apparently both had
significant changes, so someone should probably look over the changes and make
sure they're doing the same thing as the old code was supposed to.

Please test, those of you who want to see this!

        Attachment #67900 -
        Attachment is obsolete: true

    
    

    
  
Akkana, thanks for updating it. I have another massive profile mgr patch in my
tree now, but I can review your update. Sorry this fell off my radar :-/
Target Milestone: mozilla1.0.1 → mozilla1.2beta

    
    

    
  
Our office is anxiously awaiting some resolution to this issue as we have a few 
hundred windows users who cannot move out of Netscape 4.8 until the salted 
profile issue is resolved. Have there been any updates with a manageable 
solution for windows to not use salted profiles?

    
    

    
  
Finding the salted directory isn't too hard in a corporate type domain
environment since each logon user will have a separate profile and %appdata%
path. Therefore you really should only have one salted directory to worry about
and can just grab a dir listing to find it.

For example, below is a vbscript snipet that will do that. To do it in batch,
just cd to the profile\profilename and then "cd *.slt"

Example vbscript:

Function GetDest
' Requires: A big assumption that there is only one salt dir in a profile
'           %userprofile% be defined and set to user's win profile dir
'           "mozilla -CreateProfile default" command already run
' Effects:  Returns one path to where prefs.js should be overwritten
'           This path includes the mozilla random salt dir 

Dim sProfile
Dim oSubdirs   ' File listing of default profile directory
Dim oSaltDirs  ' Salt dir object
Dim sSalt      ' Salt directory name
Dim oShell
Dim oDir

Set oShell = CreateObject("Wscript.shell")
Set oDir = CreateObject("Scripting.FileSystemObject")

' Find value of userprofile env var
sProfile = oShell.ExpandEnvironmentStrings("%APPDATA%")
sProfile = sProfile & "\Mozilla\Profiles\default\"

on error resume next
set oSubdirs = oDir.GetFolder(sProfile)

if oSubdirs = Empty then
   GetDest = "notfound"
else
   for each oSaltdirs in oSubdirs.Subfolders
     sSalt = oSaltdirs.Name     ' There really should be only one. If not, heh!
   Next
   sProfile = sProfile & sSalt & "\prefs.js"
   GetDest = sProfile
end if

Set oShell = Nothing
Set oDir = Nothing

End Function

    
    

    
  
Ken, what you propose is fine if you're using roaming profiles, or if you only
need access from a single location.
If, however, you store your Mozilla profile in a network-accessible location
like your home directory (ie h:\mozilla), you need to point
%APPDATA%\Mozilla\registry.dat to that location (of course, resistry.dat is not
text-editable). Being able to specify the Mozilla profile directly in
registry.dat will allow network users to 'roam' to different machines and
maintain their Mozilla profile without having to use Windows' Roaming Profiles
feature.

Apparently, the linux equivalent of registry.dat is currently text-editable, so
this is not a problem on that platform.

Alternatively, if the profilemanager would have an option to not 'salt', then we
could leave registry.dat in its un-editable state yet achieve the same result by
specifying the 'correct' mozilla profile directory when its created.


    
    

    
  
I agree, I was just trying to be helpful. There is another bug relating somewhat
to this, and that is bug 110832 -- which was marked a duplicate of bug 162025
even though, IMO, bug 110832 has a better description of the problem. And that
problem is the lack of support for UNC paths. This is a real killer if your
group policies redirect %appdata% to a UNC share (and mapping to a network drive
letter is not possible since appdata gets defined during logon before any drives
are mapped). 

It seems registry.dat must reside in %appdata% and moving %appdata% is not an
option due to UNC issue. Perhaps a HKLM registry key that could point to where
to find profiles would at least allow the entire tree to move elsewhere (outside
the user profile, like to their home directory) which would help work around the
lack of support of UNC paths. Netscape 4.x found its profile location this way
and we used that to move the profile tree. 

While this bug is marked enhancement and the others are critical, all together
they create a hostile environment to rolling out any Mozilla-based product in a
large environment. We're trying where I work and have had some limited success
with some scripts run at logon. Whenever we have something workable and tested,
we intend to publish the scripts in hopes it will help others.

Also, having registry.dat be a text or XML file would go a long way in helping
us as well...

    
    

    
  
> Also, having registry.dat be a text or XML file would go a long way in helping
us as well...

See bug 174522.

The other bug which would make salting less of a headache is bug 137006. That
will allow you to move the profile dir from place to place without it having to
have the same absolute path (which includes the salt)

    
    

    
  
it would help if we had a -CreateProfile which *just* created a profile...

currently you can do:
-CreateProfile "somename /some/path"
and it'll create and use that profile.

I'd prefer:
-Create /somepath -Profile Somename

this allows:
mozilla -Create "c:\documents and things\mozilla\junk" -Profile Test

where Create would mean create a profile and don't launch.

    
    

    
  
*** Bug 178873 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.2beta → mozilla1.3beta

    
    

    
  
I probably should stay quiet, but having read through this and most of the
original bug #56002, I'm a bit confused.  As far as I can tell, the only place
where files are put without user intervention is the cache directory,  not to
the profile directory as a whole.  At least, that's the only attack I've seen
mentioned.  Would a solution to this problem be to salt the cache dir only,
instead of the entire profile directory?  Or is there some other attack?

    
    

    
  
Historically, there have also been attacks against the prefs.js file and the
cookies file, to name just a few. Passwords and certificates are stored in the
profile directory too; the salting provides an extra layer of protection for
those too.

    
    

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

    
    

    
  
I'd like to have this salting issue resolved soon as well. I work at a public
library and our public workstation upgrade to Mozilla has been stalled because
of the difficulty in supporting *many* computers with different salted directory
names.

I'd like to see an option during the installation process asking to use salted
or specified (with a browse option) directory names. Another option would be the
use of a switch when starting the installation process that would allow you to
specify predefined directory name.

    
    

    
  
Let's worry about getting rid of absolute paths in profiles, which is the reason
why salting is a problem, in 1.4.
Target Milestone: mozilla1.3beta → Future

    
    

    
  
I agree that fixing the absolute path problem should be first priority, but is
there really no hope for getting the existing patch in as an optional behavior
for people who need it?  This is one of the top two or three issues that I get
beat up for when sysadmin types find out I'm involved with mozilla.

Can you clarify the problem with the existing patch, so I can at least pass that
along to people who ask?  (Aside from bitrot.)

    
    

    
  
OK, akkana. I just took another look at the patch and liked it better than I
remembered. As a temporary measure, I don't see any harm in it.
Target Milestone: Future → mozilla1.4alpha

    
    

    
  

      
      
      
      

        Attached patch
          
          
        fresher patch
        — 
          — Splinter Review
      

    


  
Same as attachment 103096 [details] [diff] [review] with 2 things fixed:
an instance of NS_NAMED_LITERAL_STRING in global scope.
new code uses nsIPromptService.alert instead of window.alert.
Tested again, works great.

        Attachment #103096 -
        Attachment is obsolete: true

        Attachment #116252 -
        Flags: superreview?(alecf)

        Attachment #116252 -
        Flags: review?(akkana)

    
    

    
  
Comment on attachment 116252 [details] [diff] [review]
fresher patch

r=akkana

Builds and works on linux.

I have to mention the >80 character lines in newProfile1_2.js and
nsProfile.cpp, but it's your module and your choice whether to shorten them.

>+  
>+  // and that the page is valid  
>+  if (!wizardManager.WSM.PageIsValid())
>+    return;

Does this end up calling the new validate()?  I'm not familiar with
wizardManager methods.

>+  // XXX This used to be getter_Copies(oldLeafName).  Check ownership!
>+  rv = aDir->GetLeafName(oldLeafName);

Have you checked?  I think it's okay, but please double-check.

>-    NS_ENSURE_ARG_POINTER(profileName);  

No longer needed?

>+    // Make profile directory unique only when the user
>     // decides to not use an already existing profile directory
>+    if (!useExistingDir)

I might have been misunderstanding the logic, but I couldn't seem to get this
to work -- I tried creating a profile named "default" with a directory of
~/.mozilla/foobar, and it created ~/.mozilla/foobar/default-fxv0maln (I
expected ~/.mozilla/foobar/default or ~/.mozilla/foobar).  That's not a big
deal, since that's a minor part of this patch and I'm probably just
misunderstanding the intent of the comment.

None of these comments/questions block the review -- it looks good!

        Attachment #116252 -
        Flags: review?(akkana) → review+

    
    

    
  
Comment on attachment 116252 [details] [diff] [review]
fresher patch

+    // Append profile name. This prevents people from choosing some important
directory
+    // as their profile directory and then deleting it when they delete the
profile.
+    profileDir->Append(nsAutoString(aProfileName));

use nsDependentString here

I'm not so keen on only salting the default directory though! I don't believe
that it is "random enough" - for instance, what if I use "alecf" as a login to
a lot of web sites, and one of those web sites just guesses that my profile
directory is "alecf"

That defeats the purpose of this whole thing on all profiles other than the
default. Besides, is "default" localizable in any way?

In any case, I'm fine with being able to override it, but I don't understand
this particular requirement w.r.t. "default"

holding my sr= until we hear word. I'd like to hear perhaps from mstoltz on
this.

    
    

    
  
looking back over the bug, I see that in fact mitch is ok with this. But I must
ask again.. because I really feel like I would name my extra directory "alecf"
and that I use that all over, and that that string appears elsewhere on the
disk. What if its the name of your machine, or something similarly guessable. If
I'm an attacker is it really that much work to make a few guesses based on
information I might know about the user?


    
    

    
  
Okay, so you want to view the name of the profile directory as some sort of low
grade password.  Fine - just tell that much to the user!
Ask him whether he wants to select a name to the profile directory himself, and
tell him that this name is a "low grade password" (i.e., he should not use
something easily guessable, but he should not re-use a valuable password - like
his ATM PIN - either because, after all, this will be a directory name).

    
    

    
  
Comment on attachment 116252 [details] [diff] [review]
fresher patch

ok, my condition for reviewing this is to have mitch r= this... 

mitch, akkana has done the bulk of the reviewing here, but please see comment
82 and comment 83

I guess I don't see a good reason to make all non-primary profiles unsafe just
because a few people want to be able to hack in their profile directory.

        Attachment #116252 -
        Flags: review+ → review?(mstoltz)

    
    

    
  
Comment on attachment 116252 [details] [diff] [review]
fresher patch

removing from my review queue - please re-add me when mitch reviews.

        Attachment #116252 -
        Flags: superreview?(alecf)

    
    

    
  
How about this: always salt the default profile. Salt non-default profiles if
they're placed in the normal profile directory, but don't salt them if they're
put somewhere else. As I said in comment 10, I think that saving the profile to
a nonstandard location is protection enough. I agree with Alec that since a
non-default profile is likely to be named with an easy-to-find username, it will
not be sufficient protection against an attack directed at an individual (it
would foil attacks directed at random visitors to a site).

I'm not qualified to r= this patch, because I don't know this area of the code
very well, but I would like to see salting of non-default names if they're in
the default directory; Alec can r= the actual patch.

        Attachment #116252 -
        Flags: review?(mstoltz) → review?(alecf)

    
    

    
  
-> 1.4b
Target Milestone: mozilla1.4alpha → mozilla1.4beta

    
    

    
  
Comment on attachment 116252 [details] [diff] [review]
fresher patch

ok, since this doesn't do what mitch suggested, I'll cancel the review request
for now...

        Attachment #116252 -
        Flags: review?(alecf)

    
    

    
  
What mitch suggested in comment 87 was what my original patch did, back around
comment 16, but then somebody didn't like that... I love it :-)

    
    

    
  
I don't care if we add a salted subdir or append salt to the profile name; do
whatever makes it easier to use.

    
    

    
  
> I don't care if we add a salted subdir or append salt to the profile name;
> do whatever makes it easier to use.

If it were easier to use as-is this bug wouldn't exist. <grin>  The point here
is to remove the existing salting (from the subdir and the profile name),
because *any* randomness makes it harder to use for people who want to rely on
scripting.  I'm sure I'm not saying anything that's hasn't already been said - I
just wanted to insert a reality check that, as far as this bug is concerned,
salting is a bad thing.  The only question is under which conditions it's "okay"
to over-ride the existing behaviour.  I feel like we've gone in a big circle here...

    
    

    
  
Nominating for 1.4b because it blocks mass adoption by corporations.

Seems that there is an overprotection which isn't really justified in the
context under consideration. With a disclaimer, users will share the blame
(comment 84). Looking at it from a real life (tm) perspective, most people will
just use the default directory which will be salted, with other goodies, etc. It
is with corporations that the difficulty lies. And with corporations, what do we
have? Sysadmins who know/understand the risks, proxies, etc.

In my case for example, sysadmins in our department are so far refusing to
settle on Nav7 as the default mailer/browser due to this _single_ bug which
prevents preparing profiles for users (same as comment 64 and comment 66). For
admins who are willing and _able_ to "control" things and deal with the
consequences (whatever that might be) the salt seems to be taking a customizing
power away from them. They know/understand all the prose about the salt, etc,
but for the sake of mass deployment, they wish to be able to override it. 

Please give the fix a try in the next release, with the caveat that it can
always be reverted back if testing on the terrain shows that the risks indeed
outweigh the benefits.
Flags: blocking1.4b?

    
  
Flags: blocking1.4b? → blocking1.4b-

    
    

    
  
Henrik Gemal just posted an excellent workaround to this problem in a blog entry:

http://gemal.dk/archives/000178.html

    
    

    
  
This whole thing is ridiculous to say the least IMHO. It was stated early in the
comments that "salting" the directory is a security issue. Bah humbug, if you
believe that then I have the proverbial land in Florida or the Brooklyn Bridge
for sale. The point is that IF somebody can hack into your computer, it makes no
difference WHAT the directoy is named, SLT or not. Once you're in you're in and
guessing isn't necessary after that. Hacking in to an unprotected port 137 or
139 is a piece of cake and likewise for finding the profile directory and
related info therein.

Communicator profile directories weren't "salted". Was there ever a security
breach of immense proportions to now warrant this?

Just UNsalt and be done with it.


    
    

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

    
    

    
  
I have been watching this bug for well over a year now.  I have found ways 
around this salting "feature" (mainly hexediting the registry.dat file) but 
none that gave me a warm enough feeling to go ahead and deploy Mozilla to my 
organization.  So we limp along with Netscaoe 4.x as our default e-mail client 
and it's pretty much now useless web browser.  I have to tell folks to use IE 
as a workaround to problems in the older Netscape browser.

I would think that Mozilla.org would prefer to have 
Mozilla/Firebird/Thunderbird deployed in schools, libraries, government 
agencies or small to large corporations.  This issue of salted profile names 
prevents the easy deployment and management of Mozilla in any enviroment 
larger than a handful of PC's.  The folks that have commented in this thread 
know how Mozzila works, know why there is a perceived "need" for salted 
directories, and are asking for some simple workaround to turning off salting 
so they can move on and deploy Mozilla in their businesses.  Is that such a 
bad thing?  

Go ahead and leave directory salting on by default, don't worry any more about 
confusing the user.  In my opinion in it's current state is is already 
confusing but so be it.  If you want to hide it from the masses to lessen 
confusion, just make a command line option to turn off salting. We're not 
asking for a new CCK here.  Please just give us sysadmins and network 
administrators the ability to use our current tools and knowledge so we can 
deploy Mozilla to an unsalted directory of our choosing.

    
    

    
  
Salted profiles are a completely ridiculous security measure. 
The salt can be easilly guessed with no more than 1 line of code from a
malicious script, and it is really annoying when it comes to backup and scripted
user profile configuration. I've read all the complaints in other bugs about
this issue and I cannot understand why this thing still exists.

    
    

    
  
Please post your "one line" code script as a security bug.

    
    

    
  
Add mine to the chorus of voices asking for salted directories to be optionally
disable-able during Profile Creation.  

    
    

    
  
(In reply to comment #100)
> Add mine to the chorus of voices asking for salted directories to be optionally
> disable-able during Profile Creation.  

If you want to be "added to the chorus" then VOTE for the bug, not as a reply.

    
    

    
  
I suggest closing as the latest versions do NOT append the salt directory, when the profile is created from the command line.

OK, I would personally prefer to be able to disable it from the GUI as well, but I guess that is an OK solution...


    
    

    
  
one of the best references/recommendations I've found for encouraging financial institutions to support firefox is located at bankers on-line web site 

http://www.bankersonline.com/security/security_browserthreat070204.html 

It was written in 2004 during the download.ject attack, but much of it still applies today.  This is a good link to send when contacting banks.

QA Contact: agracebush → profile-manager-backend

    
  
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 11 years ago
Resolution: --- → WORKSFORME
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: