Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4420020

File.canWrite returns invalid results as Windows 2000 User

    • Icon: Bug Bug
    • Resolution: Won't Fix
    • Icon: P4 P4
    • None
    • 1.1.8, 1.2.2, 1.4.0
    • core-libs
    • x86
    • windows_nt, windows_2000

      Name: mt13159 Date: 02/28/2001


      A problem has arisen in conjunction with File's canWrite method and
      members of group User under Windows 2000.

      Like NT, Windows 2000 has an Administrator group. Win2K also has a
      Power Users group, which is akin to a standard user under NT. New to
      Win2K is the Users group, which is severely restricted...

        Members of group User can read the entire Registry, but can only
        cause updates to occur in HKEY_CURRENT_USER.

        Members of group User cannot write to C:\WinNT or C:\Program Files
        or to subdirectories of C:\WinNT or C:\Program Files, unless the
        Administrator has specifically granted such privileges.

        To use a generic example, let's say a user gets a new machine with
      Windows 2000 installed. The machine is missing Netscape. A member
      of group User cannot install Netscape as it modifies Registry entries
      outside of HKEY_CURRENT_USER, and typically installs to the C drive's
        Program Files directory. An Administrator would have to install the
      software, and configure it for the User.

      Now for the Java problem. Class File contains the method canWrite,
      which determines write accessibility for a file or directory. In the
      underlying C code, canWrite calls access. access checks the file or
      directory's permissions, and returns 0 for success or -1 for failure.

      The problem is that access *ONLY* checks the file or directory's
      permissions. It knows nothing about system security.

      By default, C:\Program Files has the A and R attributes set. R says
      the directory is not writable. Calling canWrite on this directory
      returns false, as the directory's permissions do not allow writing.

      But the C:\WinNT directory, and most of the directories inside of
      C:\Program Files, do not have the R attribute set, meaning they are
      available for writing. Calling canWrite on these directories returns
      true, suggesting they're available for writing when, in fact they are
      not because of the additional layer of Windows 2000 security.

      Example...

      import java.io.File;

      public class FileTest
      {
        public static void main(String[] args)
        {
          if (args.length != 1) {
            System.out.println("usage: java FileTest filename");
            System.exit(1);
          }
          File file = new File(args[0]);
          if (file.exists() == true) {
            System.out.println("exists");
            if (file.canWrite() == true) {
              System.out.println("can write");
            } else {
              System.out.println("can't write");
            }
          } else {
            System.out.println("doesn't exist");
          }
        }
      }

      If the above code is run by a member of group User, as follows, the
      results are incorrect...

      java FileTest c:\winnt
      exists
      can write

      This is wrong. A member of group User does not have write access to
      C:\WinNT.

      java FileTest "c:\program files"
      exists
      can't write

      This is correct, only because the of the R attribute on the Program
      Files directory.

      java FileTest "c:\program files\common files"
      exists
      can write

      This is wrong. A member of group User does not have write access to
      this directory.

      Here's an example specific to C...

      #include <stdio.h>

      void main(int argc, char **argv)
      {
        if (argc != 2) {
          printf("usage: filetest filename\n");
          exit(1);
        }
        if (access(argv[1], 0) == 0) {
          printf("exists\n");
          if (access(argv[1], 2) == 0) {
            printf("can write\n");
          } else {
            printf("can't write\n");
          }
        } else {
          printf("doesn't exist\n");
        }
      }

      As above, the results of this code are wrong. The test for write
      accessibility doesn't work, as access simply doesn't know to test for
      system security.

      I recommend testing this with a fresh version of Windows 2000. This
      way you'll be testing with a system that hasn't been altered by the
      Administrator, giving write access to members of group User.

      After performing the install, create a new user. Add this person to
      the Users group, log out, log back in, and run your tests.
      (Review ID: 117807)
      ======================================================================

      Additional information provided by licensee:

      The workaround I provided turns out to not be a complete fix. There
      are a number of other issues that I came across after filling the bug.

      First, the Windows specific code snippet I provided is only capable of
      determining whether the user has write permission based upon system
      security. It doesn't look at file permissions, which may differ from
      system security.

      In other words, the Windows specific code may determine a file system
      is writable, but it can't tell whether or not the file is read only.
      So it's still necessary to test file permissions using access().

      Additionally, there are issues not only with canWrite, but also the
      other functions such as canDelete. This is a little weird, so bear
      with me.

      If you set a Windows directory to be read only, you would expect the
      contents of the directory to not be writable. Unfortunately, this
      isn't the case. "attrib +r directory" only prevents the directory
      from being renamed, moved or deleted. It doesn't prevent a user from
      creating, modifying or deleting files from within the directory.

      As a result, canWrite and canDelete may not return proper results.

      Overall, the classes for testing files or file systems don't exactly
      work properly on Windows due to quirks in the OS.

            alanb Alan Bateman
            mthakore Mayank Thakore (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: