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

["Andrew Schwartzmeyer (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/MESOS-3176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Schwartzmeyer reassigned MESOS-3176:
-------------------------------------------

    Assignee:     (was: Andrew Schwartzmeyer)

> Replicate *nix permission logic in Windows using the NTFS ACL API.
> ------------------------------------------------------------------
>
>                 Key: MESOS-3176
>                 URL: https://issues.apache.org/jira/browse/MESOS-3176
>             Project: Mesos
>          Issue Type: Task
>            Reporter: Andrew Schwartzmeyer
>            Priority: Major
>              Labels: containerizer, stout, windows
>
> From a forthcoming comment in stout/windows/permissions.hpp:
> {code}
>   // 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.
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)