[MESOS-3176] Replicate *nix permission logic in Windows using the NTFS ACL API.

• Type: Task
• Status: Accepted
• Priority: Major
• Resolution: Unresolved
• Labels: containerizer stout windows
• Assignee: Unassigned
• Reporter: Andrew Schwartzmeyer
• Shepherd: Andrew Schwartzmeyer
• Created: 30/Jul/15 19:26
• Updated: 17/Jul/18 20:04

Description

From a forthcoming comment in stout/windows/permissions.hpp:

  // TODO(hausdorff): (Tracked as MESOS-3176) On Windows, we currently don't
  // support User, Group, or "Other" permissions -- everyone is in one big
  // group; we also currently only support setting write permissions (i.e.,
  // everyone can write, or no one can) -- so, on Windows agents, any user can
  // read and execute a file.
  //
  // WHY: Currently we're using the DOS permissions model because it's easier.
  // In the long term we want Windows agents to replicate the *nix model of file
  // permissions by transitioning from the DOS model to the NTFS ACL API. This,
  // however, is a significant work item in itself, and will not be done for
  // the Windows MVP.
  //
  // The longer story is, the permissions model we currently use is the
  // (extremely primitive) DOS model. The CliffsNotes version of the DOS
  // permission model follows:
  //
  //   * There is one type of privilege: write privilege.
  //   * All files can be read
  //   * Therefore, there is no native notion of "User", "Group", or "Other"
  //     permissions.
  //   * There is no concept whatsoever of execute permissions; if a file can
  //     be read (and it definitely can), and if it's a binary, you have
  //     execute permissions.
  //   * All in all: the DOS model is arguably ok for situations where there is
  //     a single user in a location that can be considered "secure."
  //
  // The practical impact of this is that most of the permissions-oriented APIs
  // in Stout will _pretend_ to set appropriate permissions on Windows, but
  // mostly set them to "global writable" instead.
  //
  // This is clearly not the ideal permissions scenario for Mesos. The other
  // option is to use the NTFS Access Control List (ACL) API, and in the long
  // term we will want to transition to that. The CliffsNotes version of the
  // ACL permission model is as follows:
  //
  //   * An ACL is a list of security specifications (each specification is
  //     known as an "Access Control Entry") that describes the access model of
  //     an "object." An "object can be a process, a file, an event, or
  //     anything else that has a security descriptor.
  //   * Privileges can be granted by a process with required privileges.
  //   * The ACL model is very fine-grained: access can be granted to a user, a
  //     group, or "other", and can be split up by read, write, and execute
  //     permissions.
  //
  // BUT, and here is the kicker, the ACL model is dramatically more
  // complicated, and not worth doing in the MVP. Our goal in the future is to
  // find a more permanent solution; for now, we have a non-invasive Unix-based
  // permission model, and that will work for now.

Issue Links

• duplicates: MESOS-7768 Implement permissions handling
• is duplicated by: MESOS-3412 Revisit Unix-to-Windows permissions mapping
• relates to: MESOS-7768 Implement permissions handling