Closed Bug 24461 Opened 25 years ago Closed 25 years ago

Add new function PR_OpenFile that implements the file mode

Categories

(NSPR :: NSPR, enhancement, P3)

Product:
NSPR
Component:
NSPR
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: wtc, Assigned: wtc)

References

Details

The current NSPR function for creating a file, PR_Open,
ignores the 'mode' argument (file mode) on non-Unix
platforms.  In NSPR 4.0, we will add a new function
PR_OpenFile, with the same prototype as PR_Open, that
implements the file mode on non-Unix platforms to the
extent possible.  In particular, file mode will be
implemented using a security descriptor with an
appropriate discretionary access-control list on
Windows NT.

There are some issues with the implementation of file
mode on Windows NT.
1. NT security is only supported in NTFS.
2. On Unix, the actual file mode of the new file is
  the 'mode' argument to PR_Open modified by the caller's
  file mode creation mask (umask) -- bits set in the
  file mode creation mask are cleared in the actual file
  mode.  Windows NT does not have the notion of umask,
  so umask is effectively 0.
3. On Unix, one does not need any access permission to
  read the file mode of a file.  However, on Windows
  NT, one needs the READ_CONTROL access to read the owner,
  primary group, and discretionary access-control list
  of an object.  To emulate the Unix behavior, we will
  need to grant READ_CONTROL access to all users (the
  Everyone group).  It's not clear whether we need to
  do this.
Status: NEW → ASSIGNED
The implementation of PR_OpenFile is checked into
NSPRPUB_RELEASE_4_0_BRANCH.

Added file: ntsec.c
Modified files: prio.h, _beos.h, _macos.h, _os2.h,
_unixos.h, _win95.h, _winnt.h, primpl.h, pr/src/Makefile,
prfile.c, pr/src/md/windows/Makefile, ntio.c, ntthread.c,
w95io.c, w95thred.c, ptio.c

Some notes on the implementation:
1. In the pthreads version of NSPR, PR_OpenFile is
  the same as PR_Open.
2. In classic NSPR, each platform needs to define
  _MD_OPEN_FILE.  For Unix, _MD_OPEN_FILE is the
  same as _MD_OPEN.  For WINNT and WIN95 (which can
  also be used on an NT machine), _MD_OPEN_FILE,
  which is different from _MD_OPEN, implements the
  file mode.  On other platforms, I temporarily made
  _MD_OPEN_FILE the same as _MD_OPEN, but each of
  these should be examined to see if file mode can
  be implemented.
3. In the WINNT/WIN95 version of _MD_OPEN_FILE, I do
  not grant the READ_CONTROL access to all users.
  This means a user (other than the owner) who doesn't
  have read access to the file cannot read the owner,
  primary group, and discretionary access-control
  list of the file.
Some notes on my implementation of _MD_OPEN_FILE
for Windows NT (see ntsec.c).

I use NT's security descriptors with appropriate
discretionary access-control lists to implement
file mode.  The security identifiers (SIDs) for
owner, primary group, and the Everyone (all users)
group are looked up during NSPR initialization and
saved in global variables, so that _MD_OPEN_FILE
doesn't have to look them up every time.  When a
new file is created, _MD_OPEN_FILE constructs a
discretionary access-control list with three
access-control entries, one each for owner, primary
group, and Everyone.  The read, write, execute bits
in the specified file mode get mapped to NT's
GENERIC_READ, GENERIC_WRITE, and GENERIC_EXECUTE
accesses.
I discovered that our BeOS code (_MD_open in
bfile.c) calls open() to create a file, passing
the 'mode' argument through, just like Unix.
So we are fine on BeOS.
*** Bug 3986 has been marked as a duplicate of this bug. ***
Other NSPR functions that take a 'mode' argument are
PR_MkDir, PR_OpenSemaphore, and PR_OpenSharedMemory.

We'll need to add a new function PR_CreateDirectory
and let PR_MkDir keep the old behavior of ignoring
'mode' on Windows.

As for PR_OpenSemaphore and PR_OpenSharedMemory, it
should be okay to change their behavior because there
are no users of these two functions that I know of.
I made the following changes to NSPRPUB_RELEASE_4_0_BRANCH:
- I added a new function PR_MakeDir, with the same prototype
  as PR_MkDir, that implements the mode argument.
- I changed the Windows implementation of PR_OpenSemaphore and
  PR_OpenSharedMemory to implement the mode argument.  Note
  that this is a change of behavior and will be documented in
  Bugzilla bug #23641 as backward compatibility issues for
  NSPR 4.0.
I found an extremely useful tool called Check_SD.exe,
which is a sample application in MSDN Library. Check_SD.exe
dumps the NT security information of a file or directory.

I used this tool to look at the security descriptors
corresponding to the standard file and directory access
permissions on Windows NT (as set by the Security
Properties window).  I found that the standard Windows
NT file and directory access permissions do not have
a direct mapping to the Unix file and directory access
permissions.  In the end, I decided to have PR_OpenFile
and PR_MakeDir implement the Unix/Posix file and directory
access permissions.  This means that the files and
directories created by PR_OpenFile or PR_MakeDir may
be shown to have "Special Access" permissions in their
Security Properties window.

One example of the difference between NT and Unix
file security models is the right to delete a file.
In Unix, this is solely controlled by the write
and execute/search permissions on the containing
directory and has nothing to do with the read or
write permission on the file itself.  On NT, this
is usually controlled by the DELETE access right
on the file.  I later found that there is a
FILE_DELETE_CHILD right for directories, apparently
to implement the Unix/Posix model of file deletion
right.

I made the following changes to our NSPR-to-NT access
right mapping table for files and directories:
- I changed GENERIC_XXX to FILE_GENERIC_XXX.  GENERIC_XXX
  works, it's just that Check_SD.exe shows that the
  actual security descriptors on files all have the
  FILE_GENERIC_XXX rights instead of GENERIC_XXX rights.
- I added a separate mapping table for directories because
  the NSPR write permission should map to
  FILE_GENERIC_WRITE|FILE_DELETE_CHILD in order to match
  the Unix/Posix model of file deletion right.

/cvsroot/mozilla/nsprpub/pr/src/md/windows/ntio.c, revision 3.20.4.6
/cvsroot/mozilla/nsprpub/pr/src/md/windows/w95io.c, revision 3.16.4.4
The values of the individual flags in the "mode" argument should be defined by 
NSPR. For example, PR_OWNER_READ, PR_GROUP_WRITE, etc.
In prio.h, I defined the following access permission macros:
#define PR_IRWXU 00700  /* read, write, execute/search by owner */
#define PR_IRUSR 00400  /* read permission, owner */
#define PR_IWUSR 00200  /* write permission, owner */
#define PR_IXUSR 00100  /* execute/search permission, owner */
#define PR_IRWXG 00070  /* read, write, execute/search by group */
#define PR_IRGRP 00040  /* read permission, group */
#define PR_IWGRP 00020  /* write permission, group */
#define PR_IXGRP 00010  /* execute/search permission, group */
#define PR_IRWXO 00007  /* read, write, execute/search by others */
#define PR_IROTH 00004  /* read permission, others */
#define PR_IWOTH 00002  /* write permission, others */
#define PR_IXOTH 00001  /* execute/search permission, others */

I merely replaced the S_ prefix of the corresponding
Unix macros by PR_.

pripcsem.h and prshm.h need to include prio.h to get the
definition of these macros.

This is checked in on the NSPRPUB_RELEASE_4_0_BRANCH.
/cvsroot/mozilla/nsprpub/pr/include/prio.h, revision 3.19.4.7
/cvsroot/mozilla/nsprpub/pr/include/pripcsem.h, revision 3.2.4.1
/cvsroot/mozilla/nsprpub/pr/include/prshm.h, revision 3.2.4.1
Marked the bug fixed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.