Commits on Nov 21, 2023

1. permission: do not create symlinks if target is relative …

   The permission model's security guarantees fall apart in the presence of
   relative symbolic links. When an application attempts to create a
   relative symlink, the permission model currently resolves the relative
   path into an absolute path based on the process's current working
   directory, checks whether the process has the relevant permissions, and
   then creates the symlink using the absolute target path. This behavior
   is plainly incorrect for two reasons:
   
   1. The target path should never be resolved relative to the current
      working directory. If anything, it should be resolved relative to the
      symlink's location. (Of course, there is one insane exception to this
      rule: on Windows, each process has a current working directory per
      drive, and symlinks can be created with a target path relative to the
      current working directory of a specific drive. In that case, the
      relative path will be resolved relative to the current working
      directory for the respective drive, and the symlink will be created
      on disk with the resulting absolute path. Other relative symlinks
      will be stored as-is.)
   2. Silently creating an absolute symlink when the user requested a
      relative symlink is wrong. The user may (or may not) rely on the
      symlink being relative. For example, npm heavily relies on relative
      symbolic links such that node_modules directories can be moved around
      without breaking.
   
   Because we don't know the user's intentions, we don't know if creating
   an absolute symlink instead of a relative symlink is acceptable. This
   patch prevents the faulty behavior by not (incorrectly) resolving
   relative symlink targets when the permission model is enabled, and by
   instead simply refusing the create any relative symlinks.
   
   The fs APIs accept Uint8Array objects for paths to be able to handle
   arbitrary file name charsets, however, checking whether such an object
   represents a relative part in a reliable and portable manner is tricky.
   Other parts of the permission model incorrectly convert such objects to
   strings and then back to an Uint8Array (see 1f64147),
   however, for now, this bug fix will simply throw on non-string symlink
   targets when the permission model is enabled. (The permission model
   already breaks existing applications in various ways, so this shouldn't
   be too dramatic.)

   

   tniessen committed Nov 21, 2023
   Configuration menu

   • View commit details
   • Copy full SHA for 13b72a7
   • Browse repository at this point

   Copy the full SHA

   13b72a7 View commit details

   Browse the repository at this point in the history