[ https://issues.apache.org/jira/browse/MESOS-3176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Schwartzmeyer reassigned MESOS-3176: ------------------------------------------- Assignee: Li Li (was: Alex Clemmer) > 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: Bug > Components: containerization, stout > Reporter: Alex Clemmer > Assignee: Li Li > Labels: containerizer, stout > > 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 (v6.3.15#6346)