Closed Bug 26738 Opened 25 years ago Closed 25 years ago

signle signon writes to shared file

Categories

(SeaMonkey :: Passwords & Permissions, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED FIXED

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.
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
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.
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).
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
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.

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.  
steve, not sure how to verify this [from qa perspective] --eg, on unix just make
sure the mod of the files is 700 (rwx------)?
Just make sure that single-signon doesn't install any files in any directory 
other than the profile directory.
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
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.