Closed
Bug 26738
Opened 25 years ago
Closed 25 years ago
signle signon writes to shared file
Categories
(SeaMonkey :: Passwords & Permissions, defect, P3)
SeaMonkey
Passwords & Permissions
Tracking
(Not tracked)
VERIFIED
FIXED
M14
People
(Reporter: waterson, Assigned: morse)
Details
(Keywords: verifyme)
It appears that single signon is writing to a "shared" file, FieldSchema.tbl. By shared, I mean "something that is installed in a common directory." This is bad for several reasons: 1. It means that field information may be visible between profiles. 2. On some operating systems, the installation directory may not be writable by the current user. The reason I suspect this is that my "FieldSchema.tbl" file is always marked as "modified" by CVS on Linux after I run the app. (On Linux, files are symlinked to the install directory.) Please talk to selmer about getting this moved to the profile directory if the file is indeed read/write, and not read-only.
Assignee | ||
Comment 1•25 years ago
|
||
Yes, now that you pointed this out, it is indeed bad. There are other files that have the same problem, namely All.tbl, DistinguishedSchema.tbl, FieldSchema.tbl, SchemaConcat.tbl, and URLFieldSchema.tbl. The intent here was that these files are common to all users and that they occaisonally get updated during a browser session. That is why I put them in a common directory rather than in the profile. I didn't think of the owner problem on unix. Do you suggest that I move them to the profile directory for unix only, or for all platforms. It's not necessary to make this change for windows (or is it?).
Status: NEW → ASSIGNED
Target Milestone: M14
Reporter | ||
Comment 2•25 years ago
|
||
Both Windows and Mac will suffer from similar problems if, for example, the executable is installed on a file server. Talk to dveditz and selmer about these problems. They've seen them all before.
Comment 3•25 years ago
|
||
Yes, we have to fix this for windows as well. Communicator got a fair number of complaints from WinNT shops where the admins really lock down the machines so that users can only change their home directory files. Mozilla profiles still have some of these problems (e.g. profiles are not created in the user dir by default, users may not know how to change it or what to change it to).
Assignee | ||
Comment 4•25 years ago
|
||
Note that item 1 in the description of this report is invalid. It says that field information may be visible between profiles. That's exactly what we want. These tables are common to everybody and that is the reason I was putting them in the common resource directory. The user's private wallet data was always put in the profile directory. Item 2 of the description is valid and is suffecient reason for changing the implementation, even though it means that we will now be slightly inefficient and duplicating the identical tables in all profiles. I just checked in a fix (change was in wallet.cpp). Wallet tables are now downloaded to profile directory.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 5•25 years ago
|
||
just to pick nits, i thought it was *always* bad to share information between profiles. for example, if you saw a certain set of fields that could now be automatically mapped via schema, couldn't you infer the sites that a user had visited? anyway, i realize that i'm arguing a moot point because you've fixed this.
Assignee | ||
Comment 6•25 years ago
|
||
Continuing the moot discussion, the answer to the question you asked is NO. The shared tables had nothing to do with the sites a user had visited. All you could infer from them is when the other users last used the wallet functions. The first time you use the wallet functions per session, I want to make sure you have the latest tables (just in case they have been updated on the server). These are the tables that get downloaded into the shared area.
Comment 7•25 years ago
|
||
steve, not sure how to verify this [from qa perspective] --eg, on unix just make sure the mod of the files is 700 (rwx------)?
Assignee | ||
Comment 8•25 years ago
|
||
Just make sure that single-signon doesn't install any files in any directory other than the profile directory.
Comment 9•25 years ago
|
||
thans, steve... since i haven't seen single signon write to a directory other than the proper profile directory (on linux, winNT or mac), so am verifying this one.
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment hidden (collapsed) |
You need to log in
before you can comment on or make changes to this bug.
Description
•