Currently, on multi-user systems we do not recognize the security firewalling that is done to prevent users from harming themselves and others. In particular, on NT we force administrators to open up shared directories to general write access so their users can run our products. It would be very desirable to fix this such that profiles lived within the OS's concept of users. There are some proposals on netscape.public.mozilla.prefs which address this concept.

Current thought is to always ensure that an "OS user" directory exists even on single-user systems. That way, the profile manager code can depend on the directory in a cross-platform fashion. This implies the file locator should be able to create the directory structure necessary to accomodate the concept on single-user systems. (See the newsgroup netscape.public.mozilla.prefs for a full discussion.) On Win95/Win98, we need to create the directory <windir>\profiles\<user>\Application Data\ to contain the Mozilla or Netscape subdirectory. On WinNt, this structure should exist already. On Unix, the user's home directory will be used. On Mac... ?

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

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

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

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

Note: to find the location of the "Application Data" directory in Windows, you can use the nsSpecialSystemDirectory class with the Win_Appdata parameter.

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

Moving all Profile Manager bugs to new Profile Manager Backend component. Profile Manager component to be deleted.

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

Getting off M15 radar.

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

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

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

Reassigning to myself. Adding nsbeta2 keyword.

putting on nsbeta2- radar as this is a feature.

"Well-behaviour" a feature. Interesting POV.

I think windows2000 has a %home% setting. Windows98 might have an alternative location for profiles [we should check] This bug blocks tracker bug 41057 cri Mozilla should not need write access to the binary directory

I don't think, this blocks bug 41057. That bug is about the bin dir, which is currently a sibling to the Users50 dir on Windows, I think. They are related, however.

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

To derive profile directory, We are dependnig on install directory and hardcode path from there, on only Windows platform. On Mac, we store profile in (system) documents directory..and on Linux get home directory (and append .mozilla to store profile folders). So, we should just fix the windows part to do the right thing. Nominating this for nsbeta3.

Adding nsbeta3+.

yay!

Yancey Yeargan wrote to .seamonkey: > ALLUSERSPROFILE=D:\Documents and Settings\All Users.WINNT > USERPROFILE=D:\Documents and Settings\UserName > > The AllUsersProfile directory could be used for default settings or > "locked down" settings that you do not wish the users to change. > > The UserProfile directory would then seem to be an ideal place for the > logged on user's prefs.

I'm not going to post to the newsgroup, but Yancey Yeargan is wrong on one point: > ALLUSERSPROFILE=D:\Documents and Settings\All Users.WINNT > The AllUsersProfile directory could be used for default settings or > "locked down" settings that you do not wish the users to change. Environment variables are user controlled [windows/unix/...]. If we do want truely locked settings we'll need to use the windows registry which can have full ACL settings to prevent mortals from making changes. As for unix i think we'd have to use /etc since that's theoretically root owned. A reminder that people can forge the entire directory structure using a shell script that builds a tree of symlinks (of course you could recompile moz to disable this global rule stuff...), and then insert their own global prefs. "Good-behavior" dictates we use the function mentioned in Additional Comments From Michael Lowe 1999-10-25 10:23.

The user *can* change the environment variables, and if they have a preference why not follow it? If the user is on a locked-down machine they'd better not change the settings their admin has given them without knowing what they're doing, and if they do end up pointing at a read-only directory anyway then we could gracefully fail.

The admin is responsible the box, and if the admin makes a preference we must accept it. > if [The user has] a preference why not follow it? ? because the user shouldn't be able to override the admin's preference. > If the user is on a locked-down machine they'd better > not change the settings their admin has given them without knowing what > they're doing, and if they do end up pointing at a read-only directory > anyway then we could gracefully fail. I think you're missing my point: if the admin sets readonly prefs but the user has a writable home directory (for mail and composing web pages) then we should not allow the user to overrule the administrator. examples: library/kiosk/school wants to block stuff but still allow homespace. ->allowing the user to set an env var which overrides the institution is bad.

Win_Appdata will certainly be a good place. I just ned to check where this points on various OS versions (95, 98, 20000, NT). This one is designed to hold user specific information. Depending on the login profile, profile directories will be created in the corresponding directories...

> if the admin sets readonly prefs [...] then we should > not allow the user to overrule the administrator. Please note that the user can always change the prefs for the current session, so it makes no sense to forbid to store them.

Changing the priority to P1. Fix is ready for this. Just need to talk to dan about any issues he can think of..

Fix checked in. We now use Application Data folder as the home for user profile directories. detailed updates at news://news.mozilla.org/39AC0F4E.EB2DF5FA%40netscape.com Thanks for all those who have been holding onto it and providing valuable input/feedback.

Thanks for fixing this bug. It was important to be fixed.

verified on all platforms for builds 200008310x

We might want to release note were the default profiles folder lives, so users can access their mail files manually. Euroda also does this in its release notes <http://a1392.g.akamaitech.net/7/1392/939/0001/www.eudora.com/download/eudora/windows/5.0/Readme.txt>.

I copied "registry.dat" to the new location (E:\WINNT\Profiles\maxim\Данные\Mozilla), but I still see the following in the console: New location for profile registry and user profile directories is -> E:\WINNT\Mozilla I use the Russian Windows NT Workstation 4.0 SP6a and the build 2000103120

Max, could you please file a new bug, I suspect we're choking on unicode characters and deciding to use the fallback path.

There are still some problems (in xpcom/io level in carrying i18n data without corruption) if the user has logged into the system with international chars in the login name (as the path to Application data folder contains that name in the path). This situation has already been reported by someone who logged with japanese username. Please refer to bug 58679, before you decide on filing the bug and makesure that your situation is different from that one.

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