411969 - Creating files with mode 0600 on WinXP is very user unfriendly

Status: NEW

(NSPR :: NSPR, defect)

Description

[Nelson Bolyard (seldom reads bugmail)]

Subtitle: files with mode 0xx0 are VERY perplexing to Windows users.

I'm filing this bug against NSPR, but I'm not at all sure that's where it 
rightfully belongs.

When a user of Firefox, Thunderbird or SeaMonkey on Windows XP downloads a 
file, or saves a file received as an email attachment, the file is created
with mode 0600 using PR_Open or PR_OpenFile regardless of where (in what directory) it is created.  This causes the file to be unreadable by any 
user other than the creator and users with administration privileges, 
EVEN IF it was created in one of the directories that exists for the purpose 
of sharing files with other non-privileged users (e.g. the "Shared Documents" folder).

That may seem like the desired & intended behavior, but it is VERY unfriendly 
for Windows XP Home users (whose systems ALWAYS use Windows' "simple file sharing") and for WinXP Pro users whose systems have the default 
configuration, which is to use "simple file sharing".  

When a Windows system uses "simple file sharing" (which all WinXP home systems do, and all WinXP Pro systems do by default, unless they are reconfigured) 
there is NO WAY for any user to see (or change) a file's permissions or access control lists.  Not even administrative users can see or change those things
when the system is using "simple file sharing".  

In simple file sharing mode, all files except system files are intended to be 
created with (effectively) 0777, 0666, or 0644 permissions, and access controls are done by controlling permissions on the users' home directories.  Each user 
can control whether his home directory is accessible by all users or only by himself.  There is a special home directory for "all users", known as "shared documents", which is always world accessible.  So, when a user creates a file
in his own home directory, it will be only accessible to himself (if he's configured his home directory that way), and when he creates a file in the "Shared Documents" folder, it is accessible by all users on his system.

There is typically NO WAY for a user on such a system to ever set a file to
mode (0xx0) with an ordinary windows program, yet this is how Mozilla 
programs create files.

When a Mozilla program creates a file with mode 0600 on such a system, 
any non-privileged users other than the creator cannot access it, even if
it is in "Shared Documents".  No users (not even admins) can see what the 
problem is (because they don't have any way to see or change file permissions).

If a user simply copies a file he created with Mozilla, using (say) windows explorer, the copy will be readable by all users, because the copy will be created with mode 0666.  The users will then find there are two copies of 
the file, one accessible and one inaccesible, with no discoverable reason 
for the behavioral difference.  

So, I think Mozilla products ought not to create files witn mode 0xx0 by 
default (or perhaps ever) on Windows systems that use "simple file sharing".

This could be fixed by a change to all the many places in Mozilla code that
create files, or by a change to NSPR's PR_Open (and PR_OpenFile) routines.

Comment 1

[WADA:World Anti-bad-Duping Agency]

Possibly due to Bug 224692.
(1) Written in "Temp"(probably with 600)
(2) Move(similar to MOVE command. Not copy&delete) because same drive & NTFS,
    then Bug 224692 occurs.
(3) Network access is controlled by group name of "Everyone" (MS Win-XP SP2).
    (unable to change this because NET ACCESS is not supported on client Win-XP)
    And remote user seems to be treated as a member in group=Everyone.
    And due to 60*0*, access by group=Everyone seems to be denied.

Access to a shared resource is executed as follows.
> NET USE X: \\<computer_name>\<sharing_name>[\<subdirectory>]
>         <password> /USER:[<domain_name>\]<user_id>
> (see "NET USE /?" output at Command Prompt)

Possible workaround.
(A) Permit directory access by group=Everyone locally/explicitly.
    And apply it to all files and sub-directories via "Advanced" or "Detailed"
    for already existent files/directories.
    (Properties/Security tab)
    ("Everyone" is not listed in group/user list. Please type-in it.)
(B) Permit access to shared resource by group=Users explicitly.
    And add user_id, which is used by remote user, as a member of group=Users.  
    (Properties/Share tab)

Neil, can above be workaround? 

Comment 2

[WADA:World Anti-bad-Duping Agency]

Above question is to Nelson, the bug opener. sorry for spam.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

WinXP Home users don't have a "Security Tab".  That's only in WinXP Pro.

If WinXP Home users had a security tab, then this wouldn't be a problem,
or would be a much less serious problem, because then users could see the
cause of the problem (by looking at the security properties of a file they 
cannot access) and could fix it (or get an admin user to fix it).  But 
even then, the workaround would have to be reapplied each time a new file
is downloaded.

IIRC, in WinXP home, all access attempts by remote users are treated as 
access attempts by the local "guest" user, even if the guest login is 
locally disabled.  

I think the only real solution for WinXP Home (and its Vista equivalent) 
is to force the mode bits to always include at least 0444 when creating 
new files, or maybe even 0666.  NSPR could do that.  

Comment 4

[Masatoshi Kimura [:emk]]

FYI:
"Simple file sharing" is disabled by default on WinVista including Home editions. So this is a WinXP only problem.
Also, you could view/modify permissions using cacls command on WinXP Home. (Yeah, this is too hard for most home users.)

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.